Documentation

Split Groups and Settlement Documentation

Deep methodology for contributions, consumption shares, multi-payer obligations, deterministic rounding, settlement order and approval, offsets, debt simplification, group tools, and privacy.

Audience: Split group members, household admins, support reviewers, and anyone auditing a group balance. · 10-page PDF · v6.26.1

Logo header · watermark · generation date · multi-page

How to read this document

Sections move from purpose → concepts → calculation process → worked examples → edge cases. Formula boxes use plain mathematical notation for clarity; they are conceptual summaries, not API contracts.

Point lists call out operator-visible behaviour.
Callouts mark warnings, limitations, or important qualifications.
Worked examples use round numbers so you can reproduce the arithmetic by hand.

Purpose and boundaries

Split is a collaboration ledger for shared payments and settlements. It answers who funded a payment, who consumed its value, and how resulting obligations can be settled.

Contributions describe funding; shares describe consumption
One payment can have several payers and several consumers
Settlements reduce obligations without rewriting the original payment
Split balances remain separate from household expense totals — the one bridge is the explicit "add my share to personal expenses" option, which is user-initiated and idempotent and posts only your own portion into the household ledger

ReceiptVis on Split payments

When ReceiptVis is enabled for your account, creating a Split payment can start from a receipt scan. The draft still requires review before submit. A receipt is optional when creating a payment; a payment saved without one is not marked receipt-verified.

Scan supports multi-image long receipts where the UI allows.
Verify amount, merchant, and date before the payment is recorded.
See the ReceiptVis documentation module for entitlement and limits.

Core terms

Payment total — the full value being allocated.
Contribution — the amount a member actually funded.
Consumption share — the amount of the payment allocated to a member.
Payment net — contribution minus share.
Obligation — a directed amount from debtor to creditor.
Settlement — a recorded transfer intended to reduce outstanding obligations.

Contribution is not share

Paying money and consuming value are independent facts. Equal funding does not imply equal consumption, and equal consumption does not imply equal funding.

Members, shadow members, and joining by QR

A group can include shadow members — participants without an AccountHouse account, such as a visiting friend. Shadow members carry contributions, shares, and obligations like anyone else; their balances are simply managed by the group rather than by their own login.

Join by QR: share a group join link or QR code; the joiner sees a preview of the group before accepting.
Join links can be rotated or revoked at any time, invalidating anything previously shared.
Ownership transfer: the group owner can hand the group to another member.
Exit check: leaving a group is blocked while you still have unsettled balances, so nobody walks away from an open obligation.

Payment invariants

Funding reconciliation

Σ Contributions = PaymentTotal

A valid multi-payer allocation must fully fund the payment.

Share reconciliation

Σ ConsumptionShares = PaymentTotal

The allocation method must distribute the entire payment.

Conservation

Σ (Contribution − ConsumptionShare) = 0

Before settlements and rounding display, positive and negative member nets balance.

Validation should prevent incomplete allocations from masquerading as reconciled payments. Currency precision can require deterministic remainder assignment.

Rounding and remainder assignment

Amounts are represented at currency precision. When equal or percentage shares produce fractions of a minor unit, AccountHouse assigns the remainder deterministically rather than dropping value.

Three-way equal split

Payment total is 100.00.
Raw share is 33.333… each.
Two members receive 33.33 and one receives 33.34 under deterministic ordering.

Final shares total 100.00; no cent is created or lost.

Display order is not a promise

Public documentation describes deterministic reconciliation but does not expose internal tie-breaking constants as an API contract.

Multi-payer payments

Multi-payer entry records the actual funding composition. Each payer contribution participates in the same payment-level net calculation.

Dinner with two payers

Total is 300.
A contributes 200 and B contributes 100.
A, B, and C consume 100 each.
Nets are A +100, B 0, C −100.

C owes value toward A; B has neither receivable nor debt on this payment.

Member payment net

Net(member) = Contribution(member) − Share(member)

From member nets to obligations

Positive nets are claims and negative nets are debts. The obligation engine matches debt capacity to claim capacity without changing the economic totals.

A debtor cannot owe more than the magnitude of their negative net for the payment.
A creditor cannot receive more than their positive net.
All generated obligations must reconcile to the same currency-precision total.
The directed representation is an accounting aid; it does not initiate a bank transfer.

FIFO settlement allocation

When a settlement can apply to several open obligations between relevant parties, allocation proceeds against eligible outstanding items in first-in, first-out order. Older obligations are reduced before newer ones, subject to scope and remaining amount.

Applied to obligation

Applied = min(SettlementRemaining, ObligationOutstanding)

Settlement across two obligations

An older obligation has 40 outstanding.
A newer obligation has 70 outstanding.
A settlement of 60 is recorded.
FIFO applies 40 to the older and 20 to the newer.

The newer obligation retains 50 outstanding.

Dates matter

Backdating, editing, or deleting a payment or settlement can change allocation order and reconstructed outstanding amounts.

Partial and excess settlements

A partial settlement reduces but does not erase an obligation. A settlement amount must be interpreted within eligible outstanding value; unsupported excess should not silently fabricate a negative debt.

Record the actual transfer amount.
Check payer, recipient, date, group, and currency.
Use clear notes for combined transfers.
Correct mistakes at the settlement source.

Settlement approval and QR settle

A settlement is a two-sided record: after one side records it, the other side acknowledges or rejects it. Acknowledged settlements apply to obligations; a rejected settlement does not silently reduce anyone's balance.

QR settle lets the receiving side present a code so the payer records the settlement against the right person and group.
An unacknowledged settlement is visible as pending, not applied fact.
Rejection sends the record back for correction instead of erasing the underlying obligation.

Mutual obligations and offsets

Two members may have obligations in opposite directions from different payments. A mutual offset can present or settle the nettable portion while preserving the source obligations and audit trail.

Nettable mutual amount

Offset = min(A owes B outstanding, B owes A outstanding)

Opposite obligations

A owes B 80 from groceries.
B owes A 30 from tickets.
The mutual nettable amount is 30.
After offset, A's net directional obligation is 50.

The original payments remain visible; offsetting does not rewrite who paid.

Scope-sensitive

Offsets require compatible members, group, currency, status, and eligible records. A headline net must not conceal incompatible obligations.

Debt simplification

Debt simplification reduces a group's web of obligations to the fewest transfers that settle everyone. The economic totals are unchanged — each member's overall net position is identical before and after — only the routing of who pays whom is condensed.

Three-way chain

A owes B 50.
B owes C 50.
Simplification proposes a single transfer: A pays C 50.

One transfer settles the group; B's net of zero is achieved without B moving money.

Balance views and outstanding amounts

Outstanding

OriginalObligation − AppliedSettlements − EligibleOffsets

Never below zero for a closed directed obligation.

Group and member balances aggregate source obligations under the selected scope. Filters, permissions, edits, and settlement allocation can change the currently computed view.

Outstanding trend is not historical truth

A synthetic outstanding trend reconstructed from current obligations, dates, or present allocation state is an analytical reconstruction. It must not be described as a stored historical snapshot or proof of what users saw on a past date.

History, edits, and reconstruction

The activity timeline records meaningful events, but computed balances can be rebuilt from current valid payments and settlements. Editing an old contribution, share, date, or member can affect later obligation matching.

Use source timestamps and activity records for audit context.
Do not infer a past screen state from a current synthetic series.
Export before material corrections when the household needs an external audit artifact.
Explain corrections in notes where supported.

Currency handling

Obligations are meaningful in their recorded currency context. Cross-currency display conversion can help reporting but should not be treated as permission to offset economically distinct obligations without an explicit supported rule.

Preserve original payment currency.
Check conversion basis in aggregate reports.
Expect minor-unit rounding.
Do not assume a bank's transfer rate equals a reporting conversion.

Group modules and tools

Beyond payments and settlements, each group carries its own coordination modules.

A live group chat — text, images, and payment references — with delivery and read receipts, so the conversation about a cost lives next to the cost.
Group budgets and group payables for shared planned spending.
Recurring reminders and payment templates for repeated group costs.
Receipt gallery collecting every attached slip in one place.
Announcements for group-wide notices.
Cross-group search to find a payment wherever it lives.
Export to CSV, Excel, or PDF for external records.
An admin activity trail recording meaningful group actions.

Where Split runs

Split is available as the AH Split Android app (download it from theaccounthouse.com/download/split), as the AH Split web app at /split-app/ that shares the dashboard sign-in and session — signing into the dashboard signs you into Split on the web — and, for existing installs, inside the deprecated AccountHouse Android app (Split mode from the drawer).

Receipts are optional on a new payment; without one the payment is not marked receipt-verified.
All surfaces work against the same groups, balances, and history.

Group privacy and visibility

Split is scoped to group membership and permissions. A member may see group-level participation while sensitive peer settlement details, notes, or direct balances are limited to relevant participants or authorised roles.

Invite only intended participants.
Avoid sensitive details in free-text notes.
Review membership before exporting.
Use account and device security controls.
A household role does not automatically imply unrestricted access to every independent Split group.

Screenshots and exports

Once a participant exports or shares visible data outside AccountHouse, product permissions cannot control that copy.

Notifications and reminders

Notifications can announce payments, comments, requests, or settlement changes. They are convenience signals; the in-product ledger is the source of truth.

Delivery may be delayed or disabled.
A notification does not prove a transfer completed.
Open the payment or settlement before acting.
Security-sensitive changes may use separate alerts.

Audit and troubleshooting

A member balance looks wrong

Confirm the group and currency.
Review payment contributions and consumption shares separately.
Verify each side sums to the payment total.
Inspect settlements in date order.
Check mutual offsets and edited or deleted records.
Compare the result with an export.

The final balance should be explainable as source obligations less eligible applications.

Search for duplicate payments.
Check excluded consumers.
Verify exact or percentage totals.
Inspect rounding remainders.
Confirm settlement direction.
Review backdated edits.

Privacy, advice limits, and what we do not publish

AccountHouse is a household tracking and organisation tool. It is not a bank, payment processor, tax advisor, or investment advisor. Forecasts, health scores, balances, and alerts are informational.

Household data is scoped to your household; other families cannot see your ledger.
Public documentation explains product behaviour and calculation concepts, not proprietary internals.
Exact scoring weights, anomaly thresholds, cryptography parameters beyond high-level algorithms, and operational detection rules are reserved.
Split records obligations; AccountHouse does not move money or guarantee collection.
Synthetic outstanding series are reconstructions, not immutable historical balance snapshots.
Public methodology omits internal optimisation and abuse-detection thresholds.

Intellectual property boundary

This document describes what AccountHouse calculates and which inputs matter. It does not disclose source algorithms, secret constants, or implementation details sufficient to reconstruct proprietary systems.