Split Groups and Settlement Documentation
Deep methodology for contributions, consumption shares, multi-payer obligations, deterministic rounding, settlement order, offsets, and privacy.
Audience: Split group members, household admins, support reviewers, and anyone auditing a group balance. · 9-page PDF · v6.26.1
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
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. Mobile flows may require a receipt attachment even when OCR is unavailable.
- 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.
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.
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.
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 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.