Skip to main content
Ledger Map
Start your map

Problems

NDIS remittance has more lines than invoices

Because the remittance is one row per claim line and your ledger is one row per invoice. An invoice covering a fortnight of support carries several support items and several service periods, and each of those was claimed separately, so it comes back as several paid rows. The row count is expected. The totals still have to agree.

Key facts

What the remittance counts
One row per claim line rather than one row per invoice, so an invoice holding several support items comes back as several rows.3
How many rows one invoice can become
A single invoice covering a participant's week of services can appear as 6, 8, or 12 separate rows, in the words of one vendor guide.3
The size of a fortnightly run
100 to 300 lines across 30 to 80 participants for a mid sized provider, in the words of a second vendor guide.4
Why the grain is set before the remittance exists
The claim file is one row per support item per service period, in sixteen columns the portal reads by position. The remittance answers on that grain.1
The field that carries your invoice number
Your Reference, holding the claim reference the practice put on the upload, with a system suffix appended after it.3
The check the row count does not change
The total at the foot of the remittance stands against the single deposit on the bank feed, whatever the number of rows above it.4
Where the deposit lands
Account 102 in the allied health template, NDIA clearing, at the BAS excluded tax type, because the revenue was recognised when the invoice was raised.2

The remittance counts claims, your ledger counts invoices

A remittance longer than the invoices behind it is the normal case, not a fault. The two documents measure the same money at different grains. Your ledger is organised by invoice, because the invoice is the document you sent. The payee payment remittance advice is organised by claim line, because a claim line is what the agency assessed and approved. One invoice can hold many claim lines, so the row count is larger by construction.

RemitClear puts the mismatch plainly: your Xero ledger is organised by invoice, the remittance is organised by claim, and you will rarely have a clean 1:1 mapping between the two. That sentence is worth holding before you touch a single row, because the job in front of you is a grouping exercise rather than a matching one. Matching row to invoice is what turns an afternoon into a day.

Reviewing a remittance now takes minutes instead of ticking off invoices line by line.5

What splits one invoice into several rows

The split happened at upload, before any money moved. A row on the bulk payment request is one support item, for one participant, over one service period, and the file is read by column position. Whatever the invoice looked like, the claim file is what the agency holds, and the remittance answers on the claim file's grain.

  • Support items. A fortnight that mixed therapy with travel, a report or a non face to face activity was claimed on a separate support item code for each, and each code is its own row.
  • Service periods. A claim row carries a first service date and a last service date, so a fortnight billed as one invoice but claimed week by week comes back as two rows for the same item.
  • Claim types. A cancellation, a report writing line or a travel line is flagged on its own row rather than folded into the service line beside it.
  • Participants. An invoice raised across more than one participant is claimed per participant, so it returns as at least one row for each of them.
  • Split submissions. A bulk claim reference ties a row to one uploaded file, so an invoice whose lines went up in two uploads comes back under two of those references.

None of these is an error, and none of them is worth chasing. They are the shape of the claim, and they are set by the practice management system that built the upload rather than by the agency that paid it.

The fields that group the rows back to an invoice

Three fields on the remittance identify the payment run, seven describe the claim line and who it was for, and one carries the practice's own reference. Knowing which is which is most of the work, because the field a bookkeeper reaches for first, the payment request number, is the one that cannot be grouped: it is unique to the row.

Payee payment remittance adviceThe payee payment remittance advice drawn field by field, eleven columns from the participant's NDIS number through to the practice's own reference, each with its meaning beside the thing that surprises a first reader: the payment request number is unique per row, one clearing number covers the whole deposit, a bulk claim reference names one uploaded file, the service dates split a fortnight into weekly rows, a status can be paid, rejected or cancelled, and the practice's own reference comes back with a system suffix appended to it.National Disability Insurance AgencyPayee payment remittance adviceGenerated by the agency's payment system andarriving as CSV or PDF. One row per claimline rather than one row per invoice, with atotal at the foot that stands against asingle deposit.Participant NDIS numberThe nine digit number of the participant theclaim line was paid for.It groups rows to a participant ratherthan to an invoice, which is why it is thefallback when the practice's own referenceis missing.Payment DateThe date the agency paid the batch this rowsits in.It is the date to receipt the payment on,and it is not the service date on the row.Clearing NumberThe batch reference from the agency'spayment system.One number covers the whole deposit, so itidentifies the run rather than any invoicein it.Payment Request NumberThe agency's identifier for this singleclaim line.Unique per row. An invoice claimed as sixlines carries six of them, and none ofthem is the invoice.Bulk Claim ReferenceThe uploaded file the claim line came from.It ties a row back to a single uploadedfile, so it identifies the submissionrather than the invoice.Support Item referenceThe support item code claimed on this row.A fortnight that mixed therapy with travelor a report was claimed on a separate codefor each, and each code is its own row.Service datesThe period the claim line covers, from thefirst service date to the last.A fortnight invoiced once but claimed weekby week arrives as two rows for the samesupport item.Quantity and unit priceThe units claimed and the price per unitbehind them.The claim file fills either a quantity oran hours field, so two rows for the sameitem can be measured differently.Claimed amount and paid amountWhat the claim asked for, beside what theagency approved.They differ on a line paid at a pricelimit or at what was left in the plan.StatusWhether the claim line was paid, rejected orcancelled.A rejected or cancelled line can arrive ona later run as a negative amount, so astatus is not only about this run's money.Your ReferenceThe practice's own claim reference, carriedback on the row.The agency appends a system suffix, so aninvoice sent as INV-29802 comes back asINV-29802-zt99134862m5540177.Watch forThe grain is the claim line, so the rowcount and the invoice count are differentmeasurements of the same money.Rows can settle claims from an earlierupload, including reversals that arrive asnegative amounts.The foot of the document is the figurethat stands against the bank feed, not thenumber of rows above it.
Plate 1The remittance field by field. Only the last row carries anything the practice itself wrote.

Your Reference is the field that ties a row to an invoice, which is why the claim reference on the upload matters so much. The portal treats it as optional and it is the only handle the practice controls. It also comes back altered: the agency appends a system suffix after the reference, so a plain text search for the invoice number finds nothing until the suffix is stripped. When the remittance reference does not match the invoice works that case through.

Three totals that have to agree

Once the grouping is understood, the reconciliation is three sums rather than a list of ticks. Each one fails in a different way, and knowing which sum broke tells you what kind of exception you have before you open a single invoice.

What to total, what it should equal, and what a difference means43
What you totalWhat it should equalWhat a difference means
Every paid amount on the remittanceThe single deposit on the bank feedA second bank credit carrying the rest of the run, or a negative row you have not read yet
The paid rows carrying one invoice's referenceThat invoice's balanceA line paid short, or a line that was not paid at all in this run
The claimed column against the paid column, row by rowEach otherA price limit, a plan budget that ran out, or a rejection

RemitClear describes the grouping step the same way a spreadsheet would: sort by participant number, sum the paid amounts, and produce a participant level total, because each total is what you then look for in Xero. Sorting by the practice's own reference gives the invoice level version of the same move, and it is the one worth building if the upload carries the invoice number.

Rows that belong to an earlier run

Some of the extra rows are not about this fortnight at all. A claim rejected or cancelled after it was paid comes back on a later remittance as a negative amount, netted against that run's deposit. So a run can carry rows for invoices you settled weeks ago, and the deposit is smaller than the positive rows suggest.

This is the one case where a longer remittance really does mean more work, because a negative row takes a credit note against the original invoice rather than an adjustment to anything in this batch. Negative lines on an NDIS remittance takes that entry apart. Plan manager runs behave the same way, and their references carry a prefix of the plan manager's own, so a plan manager remittance that will not match is a separate exercise again.

When a long remittance is hiding something

A high row count is not evidence of a problem, but three things do hide inside one, and all three are found by the totals rather than by reading the rows.

  1. A missing row. An invoice with no paid row anywhere in the run was rejected or is still queued, so it stays open and goes back in a new upload rather than being written off.
  2. A duplicated claim. The same service claimed in two uploads pays twice, and the second payment shows as a row you cannot group to an open invoice.
  3. A row you did not raise. A claim reference that resolves to no invoice at all is worth an enquiry before the deposit is reconciled, because reconciling it buries the question.

The first of those is the common one and it is also the one most often mistaken for a short payment. The NDIA paid less than I invoiced separates the two.

Your invoicing granularity decides how much work this is

The gap between rows and invoices is partly the agency's grain and partly the practice's own. A practice that raises one invoice per participant per billing period has fewer rows to group and a reference that resolves cleanly. A practice that bundles a month of services for several participants onto one invoice has handed itself the harder version of the same reconciliation, every fortnight.

That is a billing decision rather than a bookkeeping one, and it is usually made in the practice management system by someone who will not be doing the reconciling. It is worth revisiting once, because it changes the shape of every remittance that follows.

Posting the deposit without ticking rows off

The bank feed carries one credit for the run, so the posting question is how many invoices that one credit can settle at once. Xero's answer is a batch payment, which is the mechanism a batch deposit for a remittance sets up, and one deposit against many invoices covers the wider case where the funder is not the agency.

Ticked off row by row beside One deposit, one balanced setTwo columns over four accounts. On the left, a remittance worked row by row: the bank line sits unreconciled while invoices are searched one at a time, the NDIA clearing account is unused, and a short paid line disappears inside a receipt. On the right, the same run posted as one balanced set: one exact match on the bank line, a clearing account that returns to nil once every row is allocated, invoices receipted for the rows that carry their reference, and any gap named on its own line.Ticked offrow by rowOne deposit,one balancedsetBank feedOne creditleft openwhile rows aresearchedOne exactmatchagainst thebatchNDIA clearing102Unused, sonothing holdsthe runtogetherCleared bytheallocatedrows, backto nilAccountsreceivableInvoicesclosed byhand, onesearch per rowReceiptedfor the rowsthat carrytheirreferenceFundershortfalls andwrite-offs 605A short paidline absorbedinto thereceiptThe gapnamed, orthe balanceleftoutstanding
Plate 2The same remittance, worked row by row and worked as one set.

The canonical templates put the receipt on the NDIA clearing account, code 102 in the allied health template, at the BAS excluded tax type, because the revenue was recognised when the invoice was raised and the deposit only moves money. A gap on a short paid line goes to account 605 carrying the original line's tax type. A rejection carries no account code of its own, because that entry belongs against the original invoice line, on the account and tax type the line was raised at.

What Ledger Map does with a long remittance

Ledger Map posts one balanced document set per deposit and leaves one exact match in the bank feed. The claim lines are grouped back to the invoices they belong to before anything posts, so the row count stops being the unit of work. A line paid short is posted as a part payment with the gap held as its own item, a negative row is posted as a credit note, and a row nobody can place is raised as a question rather than reconciled quietly.

The accounts and tax rates come from the canonical template the practice starts from, and the practice approves its map before an invoice syncs. What the product adds here is the grouping and the leftovers: the run arrives as invoice level totals with a named list of what did not fit, instead of as three hundred rows and an afternoon.

Questions

  • Why does the NDIS remittance have more lines than my invoices?

    Because it counts claim lines and your ledger counts invoices. A claim line is one support item for one participant over one service period, so an invoice covering a fortnight of mixed supports was claimed as several lines and paid as several rows. The row count being larger is the expected result, not a sign of an error.

  • How do I match the remittance lines back to one invoice?

    Group rather than match. Sort the rows by the practice's own reference, or by participant number where the reference is unreliable, sum the paid amounts inside each group, and compare that group total to the invoice. The payment request number cannot be used for this: it is unique to a single row.

  • Is a remittance with many more lines than invoices a sign something went wrong?

    Not on its own. Check three totals instead. The foot of the remittance against the deposit on the bank feed, each group of rows against its invoice, and the claimed column against the paid column on each row. A problem shows up as a difference in one of those, not as a high row count.

  • How long does the NDIA take to pay after a bulk upload?

    Provider guidance under PACE describes two to three business days from the submission date for a valid payment request, and up to about ten days where a claim needs review. Those are secondary figures from provider facing guides rather than an agency service standard, so treat them as a working expectation.

  • Why is the deposit still short after I have grouped every row?

    Look for a negative row settling a claim from an earlier upload, or for a run paid across two bank credits. Both make the money that arrived smaller than the positive rows suggest, without any line being paid short. Check the remittance total against the credits before deciding an invoice was underpaid.

Read next

Sources

Open questions

  • Every row count on this page is a vendor figure. No agency published distribution of remittance line counts could be found, and both sources quoting counts sell remittance automation, so the numbers are attributed rather than stated as fact.
  • The field list for the payee payment remittance advice rests on two vendor guides rather than a published agency layout. ndis.gov.au refuses automated fetches, so the fields could not be checked against a specification.
  • The two vendor guides disagree on the first field. One reads it as the participant's nine digit NDIS number, the other as the provider's own registration number. The claim file carries both, so a practice should check its own remittance before grouping on that column.
  • The claim file rules come from the June 2025 edition of the portal guide, read through an archived capture. Whether a later edition supersedes it has not been confirmed by a person.
  • Xero's cap on the number of invoices in one batch payment is given as 50 by one vendor and 200 by another. This page states no number, because the two disagree and neither was checked against Xero directly.
  • Whether a plan manager's remittance carries the practice's invoice number at all varies by plan manager, so the grouping method here may need a per plan manager mapping step rather than one rule.
  1. Bulk payment requests, self help guide for providers, myplace provider portal, June 2025 edition

    National Disability Insurance Agency. Retrieved 1 Oct 2025. Source updated June 2025.

    primary

  2. The canonical configuration templates, allied health by funding source and NDIS provider

    Ledger Map. Retrieved 3 Sep 2026.

    primary

  3. NDIS remittance processing in Xero, a guide for providers

    RemittanceGo. Retrieved 3 Sep 2026. Source updated 2 Jun 2026.

    secondary

  4. How to process NDIS remittances in Xero, provider guide

    RemitClear. Retrieved 3 Sep 2026. Source updated 15 Apr 2026.

    secondary

  5. RemitClear, customer reviews on the Xero App Store

    Xero App Store. Retrieved 3 Sep 2026.

    secondary

  6. Submit a bulk payment request and receive payment

    Wiise. Retrieved 3 Sep 2026.

    secondary

  7. Reconcile NDIS plan manager remittances in Xero

    ToTheCent. Retrieved 29 Aug 2026.

    secondary

  8. PACE providers guide, part 2

    Leap in. Retrieved 29 Aug 2026.

    secondary

Review

Last reviewed 3 Sep 2026 by Shane

General information for Australian allied health practices, not tax advice. Confirm a treatment with your BAS agent or accountant before you post it.

Guided onboarding

Run one real month before you go live.

Sign up, connect Zanda and Xero, and replay a month you already closed. The map is reviewed with whoever owns the books, and nothing posts until you approve it.

Start your map

Every practice starts from a template. Nothing posts until the map is approved.