Plan-manager remittances, reconciled to the participant invoices they actually paid.

Plenty of businesses get paid in batches. What makes the plan-managed version of it harder than most is the extra level in the middle: the payer is one organisation, the services belong to different people, and the invoices sit underneath them again. The deposit tells you a total. The advice is the only record of how that total was made up.

• One payer, many participants, many invoices. A single remittance can cover invoices for multiple end clients — the batch-payer case AutoRemit is built for, and the shape it was tested against.
• Remittance formats can differ between plan managers, and can vary between payment runs. Column order, labels, how participants are identified, whether the invoice number appears at all.
• The reference on the line is often not your invoice number. The plan manager numbers its own payment run, and your number may be truncated inside it, prefixed, replaced, repeated across several lines or simply missing.
• The document is a document. A PDF, a scan or an email body — not a file your ledger can consume.
• Part payments hide inside otherwise clean runs. Most lines pay in full, one pays short, and the total no longer agrees with the sum of the invoices you were expecting.

So somebody opens the advice, works out which participant each line belongs to, finds the matching invoice in Xero, records a payment against it, and goes back for the next line. Then does it again for the next plan manager, whose advice looks nothing like the first one. It is careful, repetitive work, and the cost of getting a line wrong is not the minute it took — it is a participant's invoice marked paid when it was not, found weeks later.

The line-by-line mechanics of matching a remittance to a ledger are the same whoever the payer is; they are set out in full on remittance reconciliation for Xero. What follows here is what the plan-managed case changes.

Each line on the advice is matched against your outstanding Xero sales invoices and carries its own confidence score — one per match, not one for the whole document. On a plan-managed run that distinction does most of the work, because the lines on a single advice are not all equally clear. Three of them name your invoice number exactly; one is a part payment; one refers to an invoice you have not raised yet. Scoring each line independently is what tells you which line needs attention and why, instead of handing you a document marked uncertain.

What it does not mean is that the clean lines go ahead by themselves. Automatic posting is assessed at remittance level: if a required line is unresolved or fails a posting gate, AutoRemit does not partially auto-post the remaining lines. Line-level scoring buys you a precise diagnosis; the decision to move money is still taken over the remittance as a whole.

Two things follow from the extra level in the middle:

• The invoices on one advice need not belong to one contact. One remittance covering invoices for multiple end clients is the case AutoRemit is built for, so the payer at the top of the document does not constrain what sits underneath it.
• A participant is not a match key. The payment is applied to invoices, because that is what exists in Xero. Names and service details on the advice are part of what was read, not a field AutoRemit posts against.

Where a reference is missing or does not look like yours, the invoice number is one signal among several rather than the whole match: the amount on the line, the payer and the payer's own reference all contribute to the score. That evidence is the same on any batch remittance, and it is described in full on the general page. What matters here is the rule it serves: a line that cannot be matched confidently is held, not guessed. Nothing is rounded, split or invented to make a plan manager's run balance, and an invoice reference with no counterpart in Xero is flagged as exactly that rather than attached to the nearest similar invoice.

What posts is an ordinary Xero payment against the invoice the line paid. Alongside it, the remittance document itself is attached to the payment record — so the evidence for a plan-managed allocation lives on the transaction rather than in whoever's mailbox the advice arrived in. Months later, when a plan manager queries a payment or an auditor asks how a line was decided, the advice and the decision history are both retrievable.

The payment also carries a Smart reference, which combines the invoice number with a fragment carried through from the payer's own numbering, so the Xero payment and the line on your bank statement are recognisable as the same money. On a plan-managed run the three identifiers are typically all different — the number on the advice, the shortened text that reaches your statement, and your own invoice number — and the general page works through that with an example.

One case will still need a person: if the amount that lands differs from the payment recorded in Xero, the two will not clear against each other. AutoRemit does not paper over that with an adjustment.

Most remittance advice lists companies and amounts. A plan-managed one can carry a participant's name next to service descriptions, support categories or provider types. A plan-managed remittance can therefore contain personal information and, where it reveals or clearly implies health or disability information about an identifiable participant, that information can be sensitive information under the Privacy Act — held to a higher standard than the rest. That possibility is a large part of why the site is specific about where these documents go:

• The application, your stored remittance documents and matches, and the backups are hosted in Sydney, Australia.
• Document reading runs through Amazon Bedrock within Australian AWS regions, using its Australian geographic inference profile.
• Inbound remittance email is delivered by Amazon SES in the Sydney region, to the private address issued to your organisation.
• Connections are encrypted, passwords are hashed, and support is Australian — answered in Australian business hours, not routed offshore.

How that information is handled, including the full list of services behind the site and the application, is set out in the Privacy, Security and Cookies statement.