The Remittance Split Build Standard

1. What this standard covers

One deposit that pays many invoices, and the remittance that says which. The deposit is read from the bank feed or the statement. The remittance is read line by line. Each line is matched to the open invoice it names, the lines are added up against the deposit, and when every line is explained the deposit is applied as one batch payment equal to it. When any line is not explained, a person decides it first.

The plan manager is the lede, but the job is not NDIS-only. Anyone paid in lump sums against many invoices has it:

What is out of scope. Comparing two systems that both hold the same thing, and proposing corrections, is the Two Records standard. It never applies a payment. This standard applies exactly one thing, the batch payment, and only when the deposit is fully explained. Chasing what is unpaid is the Debtor Chasing standard. This standard is what tells it an invoice was paid, so a paid invoice is never chased, and a short payment becomes an unpaid remainder a person has decided on, not an automatic reminder. Bills the business pays are the Invoice Check standard: that is payables, and this is money coming in. And a remittance PDF that arrives by email is first filed under the Document Filing standard; this standard reads it from there.

What cannot meet it, and what can. The build needs a ledger that can apply one payment across many invoices through its API, and a bank feed or statement it can read. Xero’s API has batch payments. MYOB and QuickBooks Online can each apply one customer payment across several invoices. Check that your own ledger can do this through its API before you start, because a ledger that only takes one payment per invoice cannot reconcile the bank line in one click, and so cannot pass check 8. A remittance that only ever arrives on paper can still be read, but someone has to scan it first.

Is there a ready-made version? Not yet. No product of ours applies payments to a ledger: the Office Voice Xero connection reads Xero and writes nothing to it. So this standard is a Draft, and the build is yours or a scoped build with us.

2. Which invoices did that deposit pay?

The remittance answers it, line by line, and the build reads each line exactly as the payer wrote it: the invoice number, the payer’s own reference (a participant number, a claim number, a purchase order), and the amount. The payer’s reference and any name on the line are kept on the record. They are never used to find an invoice, because two participants can share a surname and two claims can be for the same amount.

Matching runs in one order. The invoice number finds the invoice, compared without case, spaces or punctuation, so “inv 1042” is INV-1042. Then the amount is confirmed against what is still owing on that invoice. If it differs, that is an exception on that invoice. It is never a reason to go looking for another invoice that happens to be for that amount, which is exactly how a payment lands on the wrong participant.

Then the lines are added up and compared with the deposit, and the deposit comes from the bank, not from the total printed on the remittance. A remittance often arrives before the money does. It waits until the bank line is there, because the thing being explained is money that has landed, not money somebody says is coming.

3. When a line does not fit

Six reasons, a closed list. Each goes to a person with the deposit, the line, and the amounts involved:

One exception holds the whole deposit. The nine lines that matched cleanly wait with the one that did not, because applying nine of ten leaves a bank line that only half reconciles, and a half-reconciled line is harder to find later than an unreconciled one. A person records a decision on each exception line, from three:

Once every exception line has a decision, the batch is applied, and it still equals the deposit. Nothing is corrected by the machine in the meantime. It does not write off the $10 a plan manager short paid, it does not raise a credit note for an overpayment, it does not edit the invoice to match the remittance, and it does not spread a shortfall across the payer’s other invoices. The build has no way to do any of those: the only change it can make to the ledger is the batch.

4. The records it keeps, in the shape your developer needs

Six objects, keyed on the deposit. The RemittanceLine keeps the amount as text exactly as written, because a figure nobody could read must not quietly become a number.

Deposit                           # one per bank line, read from the bank
  - deposit_id                      # the bank feed's id. The key for everything below
  - amount, date, reference, payer  # amount from the bank, never the remittance
  - status (no_remittance | held | ready | applied | taken_over)

Remittance                        # every copy that arrived, kept
  - file_id, source (email | portal)
  - payment_ref                     # the payer's reference, also on the bank line
  - deposit_id (nullable until the money lands)
  - duplicate_of (nullable)

RemittanceLine                    # unique on (deposit_id, line_no)
  - deposit_id, line_no
  - invoice_as_written, payer_ref, name_as_written
  - amount_as_written               # text, exactly as written
  - amount (nullable when unreadable)
  - matched_invoice (nullable)      # found by invoice number only
  - result (matched | short_paid | over_paid |
            already_settled | no_such_invoice | unreadable)

Exception
  - deposit_id, line_no (null when the whole deposit is held)
  - kind (total_mismatch | short_paid | over_paid |
          already_settled | no_such_invoice | unreadable)
  - detail                          # the line, and both amounts where there are two
  - decision (apply_as_written | reassign | take_over), reassign_to
  - decided_by, decided_at          # a person, never the build

BatchPayment                      # unique on deposit_id: one per deposit, ever
  - deposit_id, ledger_batch_id
  - lines [{ invoice, amount, line_no }]
  - total                           # equals Deposit.amount
  - remittance_file_id              # the copy it was built from
  - applied_at

Record                            # append only, retrievable by deposit_id
  - deposit_id, kind, ref, detail, at

A BatchPayment whose total is not its Deposit's amount, or a second BatchPayment for the same deposit, is the defect this standard exists to make unrepresentable. A payment line with no RemittanceLine behind it is the other.

5. The checks, in order

The order is the claim. The bank comes first, because the deposit is the thing being explained. The lines are read before they are matched, matched before they are added up, and nothing is applied until the whole deposit is explained.

1. The deposit comes from the bank, not from the remittance. The amount being explained is the deposit on the bank feed or statement line. A remittance that arrives before its money lands waits; nothing is applied against a deposit the bank does not show.
2. Each remittance line is read exactly as the payer wrote it, never filled in. Invoice number, the payer's own reference (a participant or claim number) and the amount, as written, one line at a time. A line that cannot be read goes to a person; it is never worked out from the deposit minus the other lines.
3. The remittance adds up to the deposit, or nothing is applied. The lines must total exactly the deposit they explain. If they do not, the whole deposit goes to a person with both amounts, and no line of it is applied.
4. Each line is matched by its invoice number, then the amount is confirmed. The invoice number finds the invoice (ignoring case, spaces and punctuation). The amount then has to equal what is owing on that invoice. An amount that differs is an exception on that invoice, never a reason to look for another one.
5. Never matched on an amount or a name alone. A line with no invoice number, or an invoice number the ledger does not hold, goes to a person, even when its amount or the name on it fits exactly one open invoice.
6. Short, over, already paid, unknown and unreadable lines each go to a person with the reason. Each exception names its kind from a closed list, the deposit, the line, and the amounts involved: the line's and the invoice's for a short or an over payment.
7. Nothing is written off, credited or adjusted by the machine. The build never writes off a short payment, never creates a credit note or an overpayment, never edits an invoice, and never moves part of a line to another invoice. Each payment in the batch is one remittance line, for that line's amount, on the invoice it named or the one a person named.
8. One batch payment, equal to the deposit, so the bank line reconciles in one click. All the lines of one deposit are applied together as a single batch payment whose total is the deposit. Never one payment per invoice, and never a batch for part of a deposit.
9. One exception holds the whole deposit until a person has decided it. If any line is an exception, nothing for that deposit is applied: the matched lines wait with it. Once a person has recorded a decision on every exception line, the batch is applied once and still equals the deposit.
10. The same remittance twice, or a second run, makes one payment. A remittance often arrives by email and again from the payer's portal. Both copies, and every later run, lead to one batch per deposit, keyed on the deposit.
11. The remittance is kept with the payment it explains. The remittance file is attached to the batch payment, or filed under the batch's id where the ledger cannot take an attachment, so anyone looking at the payment can open the page that justified it.
12. For any deposit, the record shows which lines, which invoices and who decided what. Ask about one deposit and the record answers: every line as written, the invoice each was matched to, every exception, every decision with the person who made it, and the batch that was applied.
13. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
14. The pass test passes. On a real deposit and its real remittance, a line $10 short stops everything and names itself; restored, the deposit is applied as one batch equal to it, and a third run changes nothing.

6. One payment in the ledger, applied once

The deposit goes into the ledger as a single batch payment: one payment per remittance line, each for that line’s own amount on the invoice it named, totalling the deposit exactly. That is what lets the bank line reconcile in one click. Seven separate payments would each need matching to the one bank line by hand, which is the job this standard exists to remove.

Once means once per deposit. The same remittance often arrives twice: emailed by the payer and downloaded again from their portal, or forwarded by a colleague. The build also runs again tomorrow. All of those find the batch already applied against that deposit and apply nothing new. The key is the deposit, not the file, because two copies of a PDF never have the same file name.

The remittance is kept with the payment it explains: attached to the batch payment where the ledger takes an attachment, or filed under the batch’s id where it does not. Months later, when a participant’s family asks which invoice the plan manager paid, the answer is one click from the payment.

7. What stays with a person

• ✓Every exception line: a short payment, an overpayment, a line for a paid or credited invoice, an invoice that does not exist, and a line nobody can read.
• ✓Accepting a short payment as a part payment. The build never does it on its own.
• ✓Writing off a remainder, raising a credit note, or recording an overpayment. These are done by hand in the ledger, after a person takes the deposit over.
• ✓Telling the payer their remittance does not match their payment, and asking for a corrected one.
• ✓Deciding a line was meant for a different invoice. The person names it, and the amount still has to fit.

8. Run it on what you already use

The workflow lives beside the ledger, wherever the bookkeeper already works. Three ways, all held to the same checks:

• Existing tools only. A shared spreadsheet or Microsoft 365 lists hold the deposits, the lines and the exceptions, and a small script applies the batch once every line is explained. The Microsoft 365 plan lays out the lists and flows.
• A personal dashboard. Hand this page to a coding agent and it builds a page listing each deposit, its lines, and the exceptions with a decide button, against the stub until it is pointed at your ledger.
• A long-lived bot. A routine that wakes when a remittance is filed or a deposit lands, applies the deposits that are fully explained, and posts the rest to the bookkeeper in Teams, Slack or email.

How to run any standard each of these ways is in run a standard anywhere.

9. What your developer builds, and the step that needs care

One step not to hand-roll: the batch payment itself, applied only when the whole deposit is explained, equal to it, and once per deposit however many copies of the remittance arrive. Reading the lines, matching, the exceptions and the record a coding agent builds against the stub.

provider:
  stub:       local.mock_remittances
  production: none                       # scoped build, not a product

the stub                             # local.mock_remittances
  - a bank feed, a ledger of open, paid and credited invoices
  - remittance files, one of them arriving twice
  - one way to change the ledger: a batch against a deposit
  - no write-off, no credit note, no overpayment, no invoice edit

the hard step: the batch, in production
  - no hosted product applies payments. The Office Voice Xero
    connection is read-only. Build it against your own ledger
    and bank feed, or as a scoped build with us
  - check your ledger can apply one payment across many
    invoices through its API (Xero has batch payments; MYOB
    and QuickBooks Online can apply one customer payment
    across several invoices)
  - check whether it takes an attachment on that payment;
    if not, file the remittance under the batch id

stays local                          # yours, and the standard
  - reading the lines, matching, the total, the exceptions
  - every decision on an exception, which is a person's

cannot meet the standard
  - a ledger that takes only one payment per invoice
  - a build with no bank feed or statement to read the deposit from

A vendor selling remittance automation is usually selling the PDF reading. Ask them three things: what happens to the other nine lines when one is $10 short, what their build does when the same remittance arrives by email and from the portal, and whether it can ever write off, credit or adjust anything on its own.

10. A checklist to hold any build or supplier to

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. The deposit comes from the bank, not from the remittance. The amount being explained is the deposit on the bank feed or statement line. A remittance that arrives before its money lands waits; nothing is applied against a deposit the bank does not show.
• ✓2. Each remittance line is read exactly as the payer wrote it, never filled in. Invoice number, the payer's own reference (a participant or claim number) and the amount, as written, one line at a time. A line that cannot be read goes to a person; it is never worked out from the deposit minus the other lines.
• ✓3. The remittance adds up to the deposit, or nothing is applied. The lines must total exactly the deposit they explain. If they do not, the whole deposit goes to a person with both amounts, and no line of it is applied.
• ✓4. Each line is matched by its invoice number, then the amount is confirmed. The invoice number finds the invoice (ignoring case, spaces and punctuation). The amount then has to equal what is owing on that invoice. An amount that differs is an exception on that invoice, never a reason to look for another one.
• ✓5. Never matched on an amount or a name alone. A line with no invoice number, or an invoice number the ledger does not hold, goes to a person, even when its amount or the name on it fits exactly one open invoice.
• ✓6. Short, over, already paid, unknown and unreadable lines each go to a person with the reason. Each exception names its kind from a closed list, the deposit, the line, and the amounts involved: the line's and the invoice's for a short or an over payment.
• ✓7. Nothing is written off, credited or adjusted by the machine. The build never writes off a short payment, never creates a credit note or an overpayment, never edits an invoice, and never moves part of a line to another invoice. Each payment in the batch is one remittance line, for that line's amount, on the invoice it named or the one a person named.
• ✓8. One batch payment, equal to the deposit, so the bank line reconciles in one click. All the lines of one deposit are applied together as a single batch payment whose total is the deposit. Never one payment per invoice, and never a batch for part of a deposit.
• ✓9. One exception holds the whole deposit until a person has decided it. If any line is an exception, nothing for that deposit is applied: the matched lines wait with it. Once a person has recorded a decision on every exception line, the batch is applied once and still equals the deposit.
• ✓10. The same remittance twice, or a second run, makes one payment. A remittance often arrives by email and again from the payer's portal. Both copies, and every later run, lead to one batch per deposit, keyed on the deposit.
• ✓11. The remittance is kept with the payment it explains. The remittance file is attached to the batch payment, or filed under the batch's id where the ledger cannot take an attachment, so anyone looking at the payment can open the page that justified it.
• ✓12. For any deposit, the record shows which lines, which invoices and who decided what. Ask about one deposit and the record answers: every line as written, the invoice each was matched to, every exception, every decision with the person who made it, and the batch that was applied.
• ✓13. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓14. The pass test passes. On a real deposit and its real remittance, a line $10 short stops everything and names itself; restored, the deposit is applied as one batch equal to it, and a third run changes nothing.

Facts that can change, and when we checked them