Extract and Reconcile NDIS Remittance Advice

NDIS plan-manager remittance reconciliation means turning the remittance advice into line-level rows, matching each paid, partial, or rejected item back to the original invoice or claim, and tying the batch total to the bulk EFT in the bank. For an allied-health provider or disability-service provider, the working table should show the participant, service date, support item code, units or hours, rate, claimed amount, paid amount, status, rejection reason, invoice number, plan manager, EFT reference, source file, and source page.

That is the practical job when you need to extract NDIS plan manager remittance advice. The remittance is not just a payment notification. It is the evidence that tells you which participant ledger to update, which invoice line has been short-paid, which claim needs to be corrected, and whether the money in the bank agrees to the claims the clinic expected to be paid.

The mistake is treating the remittance as one batch total. A plan manager may pay several participants, service dates, support item codes, and invoice lines in a single EFT. If the clinic posts the deposit as one amount and leaves the claim register untouched, month-end looks balanced only at bank level. The operational questions remain open: which claims are closed, which are still receivable, which are rejected, and which participant records now carry the wrong status.

A useful reconciliation file works at line level. Each row should preserve the facts from the remittance and the facts from the original claim side by side: invoice number, claim or reference number, participant, service date, support item code, quantity or hours, rate, claimed amount, paid amount, status, rejection reason, and the page or file where the row came from. Those source references matter when a rejected line needs to be queried weeks later and the bookkeeper has to prove exactly what the plan manager returned.

This is not a general NDIS invoicing guide. It is also not a US healthcare payer EOB workflow with American billing codes and insurer adjudication language. In the Australian plan-managed NDIS workflow, the provider has issued an invoice to a plan manager, the plan manager has processed the claim against the participant's plan, and the provider now has to break the remittance back down into finance records that can be posted, followed up, and retained.

The end state is simple to describe, even when the batch itself is messy: the claim register shows paid, partial, rejected, or follow-up status for every line; rejected items have an owner and next action; the sum of paid lines agrees to the bulk EFT; and the remittance advice plus extraction file are stored with enough evidence for later review.

Start with the documents in the batch

The reconciliation starts before any matching formula is written. Put the source records in one place: the original provider invoice, the plan-manager remittance advice, any portal export or PRODA CSV, the bank deposit, and the claim register in Cliniko, PowerDiary, Halaxy, Xero, MYOB, or the clinic spreadsheet. The same evidence chain applies when clinics handle Medicare and DVA rebate reconciliation for allied-health payments. If the files are scattered across email, a portal download folder, and the bank feed, exceptions become harder to explain.

Remittance formats vary by plan manager, but the useful pattern is usually similar. There is a batch header with the payer, remittance date, total amount, and EFT reference. The body may group lines by participant or invoice, with support item codes, service dates, quantities, rates, paid amounts, rejected amounts, status messages, and sometimes a short rejection reason. My Plan Manager and other plan managers may present that information differently, but the reconciliation question is the same: which original invoice line did this payment or rejection belong to?

It helps to separate the document's purpose from its format. A PDF remittance, portal export, and CSV can all be remittance evidence if they explain the payment breakdown. For a broader definition of how remittance advice documents work, the accounting concept is simple: the payer is telling the supplier what a payment covers. In NDIS plan management, that supplier-side explanation needs to be granular enough to update participant and claim records.

The provider invoice is the second half of the evidence chain. It should carry the invoice number, participant or client details, service dates, support item codes, hours or units, rates, and total claim amount. The bank deposit proves cash arrived. The claim register proves what the clinic expected to collect. Reconciliation is the act of making those three views agree without losing the line-level detail in the remittance.

When the batch is ready for extraction, keep the original file names. A source file named after the plan manager, remittance date, and batch amount is easier to audit than a generic download name. The extracted spreadsheet can then include the source file and page beside every row, so a bookkeeper can move from a mismatch in Excel back to the remittance evidence without searching the whole PDF again.

Extract the remittance PDF into rows before matching

The useful output is one row per remittance line item. One row per PDF is too coarse, and one row per participant still hides the differences between support item codes, service dates, partial payments, and rejected items. The reconciliation file needs the same grain as the remittance: one claim line, one status, one paid amount.

For most NDIS remittance PDFs, the spreadsheet columns should include:

• Participant name or participant ID
• Invoice number
• Claim or reference number
• Support item code
• Service date
• Quantity or hours
• Rate
• Claimed amount
• Paid amount
• Status
• Rejection reason
• Plan manager
• EFT reference
• Source file
• Source page

Those columns are what make an NDIS remittance PDF to spreadsheet conversion useful. The paid amount can be summed back to the bulk EFT. The invoice number and claim reference can be matched against the practice system. The support item code, service date, hours, and rate give the reviewer enough detail to spot a pricing or travel issue. The status and rejection reason decide whether the line is closed, resubmitted, queried, or left open.

Invoice Data Extraction can sit at this stage of the workflow when the remittance advice is trapped in a PDF or mixed document batch. The product accepts PDFs and image files, lets the user describe the fields to extract in a prompt, and returns structured Excel, CSV, or JSON output. For a remittance batch, the prompt should describe the line-level structure rather than ask for a general summary. For example: extract one row per remittance line with participant, invoice number, claim reference, support item code, service date, units, rate, claimed amount, paid amount, status, rejection reason, EFT reference, source file, and source page.

That is the point where financial document extraction to Excel is useful. It produces the working table and source references. It does not decide whether the claim was valid under the participant's plan, whether a support item was correctly chosen, or whether the GST treatment is right. Those are provider, plan-manager, and accounting judgements that sit after extraction.

For repeat batches, save the extraction prompt or schema. Consistent column names matter because the same matching formulas, pivot tables, and exception filters can be reused each month. If a plan manager changes the remittance layout, run a small sample first and check that the extracted source page, invoice reference, and paid amount are still landing in the correct columns.

Match each remittance row to the original invoice or claim

Start with the strongest identifiers, then fall back to the facts that should be unique in combination. Invoice number is usually the first match key. If that fails, use the claim or reference number, participant, service date, support item code, quantity or hours, rate, and claimed amount. A confident match normally agrees on more than one field.

Invoice references are not always returned exactly as they were sent. A plan manager may add text, drop a prefix, truncate a long invoice number, or return a claim reference that was generated inside its own system. Duplicate references also appear when a clinic's numbering convention is too short or when several participants have related services in the same period. In those cases, the remittance row should be treated as a proposed match until the participant, service date, support item code, and amount agree.

Keep the original claimed amount and the paid amount in separate columns. If a $193.99 therapy line is paid at $193.99, the match is straightforward. If it is paid at a lower amount, the difference may be a partial payment, a price-limit adjustment, a travel issue, an exhausted plan, or a plan-manager processing error. If the remittance shows zero paid and a rejected status, the claim is still part of reconciliation because it explains why an expected receivable remains open.

The original provider invoice still matters even after the remittance arrives. Its invoice date, participant details, service date, line description, support item code, and total amount are the baseline for the match. If the clinic is reviewing invoice quality at the same time, Australian tax invoice requirements are a useful reference, but NDIS reconciliation needs more than tax-invoice compliance. The line has to agree to the claim facts returned by the plan manager.

Once a row is matched, update the claim register rather than only the accounting system. The practice record should show paid in full, partly paid, rejected, queried, or resubmitted. For Cliniko, PowerDiary, Halaxy, or a spreadsheet register, that status is what stops the same rejection being chased twice or a partly paid line being marked as fully closed.

Do not force uncertain matches through just to clear the batch. A remittance row with a missing invoice number but a matching participant, service date, and support item code may still need provider review if the rate or units differ. A row that matches the amount but not the participant is not a match at all. The reconciliation file should make uncertainty visible, not bury it in a bank rule.

Classify rejected and mismatched lines by cause

A rejected or mismatched remittance line should be classified before anyone resubmits, writes off, or adjusts the ledger. The label should explain what happened and what evidence supports the next action. "Rejected" is a status; it is not a cause.

Common causes include missing or altered invoice numbers, duplicate claim references, amount mismatches, partial payments, overpayments, plan-exhausted items, support item code mismatches, stale or late claims, stated-support issues, and price-limit breaches. Each one leaves different clues in the extracted row. A support item problem shows up in the code or category. A quantity issue shows up in hours or units. A rate issue shows up when the claimed amount and paid amount differ even though the date and participant match.

For NDIS rejected claims reconciliation plan manager work, the support item code is often the most important field after invoice number. A line billed under the wrong support category may look financially close but still fail against the participant's plan. A stated support can be even narrower: the participant's plan may require a specific item or purpose, so a line that looks reasonable in the clinic's system still needs correction before it can be resubmitted.

Allied-health travel lines deserve a separate check. From 1 July 2025, the NDIA stated that therapy providers can claim only 50 per cent of the relevant hourly price limit for travel time, and travel time should be shown separately rather than blended into the therapy session line. The NDIS travel claiming rules make this a line-level reconciliation issue, not just a pricing update. If a travel line paid at an unexpected amount, compare the service date, support item, hours, rate, and remittance status before deciding whether the issue belongs with the invoice, the plan manager, or the provider's billing setup.

The working table should also distinguish a true rejection from a partial payment. A line with a paid amount below the claimed amount and no clear rejection reason may require a plan-manager query. A zero-paid line with a rejection reason can usually go to the resubmission queue once the cause is known. An overpaid line should not be quietly absorbed; it needs review against the claim and any later adjustment notice.

Useful follow-up tags are plain and operational: resubmit corrected invoice, query plan manager, check participant plan, review support item, adjust claim register, hold for provider review, or write off after approval. The extraction file gives the evidence trail, but it should not be asked to make eligibility, plan interpretation, or accounting decisions by itself.

Reconcile the bulk EFT and apply GST coding carefully

After the remittance rows are matched, sum the paid amount column and compare it with the bulk EFT in the bank feed. The totals should agree to the cent unless the plan manager has split the payment across deposits, combined several remittances, applied an adjustment, or shown a fee or recovery separately. If the bank reference does not identify the batch clearly, use the remittance date, payer name, and total to narrow the match.

Avoid posting the entire deposit as unexplained income. The accounting file needs the same discipline as the claim register: fully paid invoices can be closed, partly paid invoices need a remaining balance or adjustment, rejected lines should stay open or move to a follow-up queue, and overpayments need review before they are treated as revenue. The extracted remittance table becomes the bridge between the bank deposit and the receivable records.

GST coding also needs care. The current GST-free NDIS supports determination applies to supplies made from 1 July 2021 through 30 June 2027 and lists management of funding for supports in a participant's plan among determined supplies, subject to the GST Act requirements. That does not mean every NDIS-related amount in a clinic's accounts is automatically GST-free. The provider or bookkeeper still needs to check the support supplied, the documentation, the participant plan context, and the accountant's treatment where the supply is less clear.

For Xero or MYOB, the remittance file should support both allocation and review. Match the bulk EFT to the related invoices or clearing account, code GST according to the support and advice, and leave rejected or unresolved lines out of income until their status is known. If the practice uses Xero, the same evidence will also support Xero BAS preparation checks, because the reviewer can trace the GST coding back to a remittance line rather than a vague bank-feed description.

At month end, the control is complete only when three numbers agree: the paid lines in the remittance working file, the amount allocated in the accounting system, and the deposit in the bank feed. Any difference should have a named reason, such as a timing difference, unresolved rejection, partial payment, overpayment, or adjustment awaiting review.

Turn the reconciliation into a repeatable month-end control

The cleanest routine is the one the clinic can repeat for every plan-manager batch. Save the source documents first: remittance advice, portal export, bank-feed evidence, original invoices, and any plan-manager correspondence. Then extract the remittance into the same line-level schema each time, match rows to invoices, classify exceptions, check travel and pricing issues, reconcile the paid total to the bank, post the accounting entries, update participant ledgers, and archive the evidence.

Keep the extraction schema stable unless the plan-manager format changes. If the spreadsheet always contains participant, invoice number, claim reference, support item code, service date, hours, rate, claimed amount, paid amount, status, rejection reason, EFT reference, source file, and source page, the bookkeeper can reuse filters, lookup formulas, and exception views. Invoice Data Extraction supports saved prompts for repeat extraction tasks, so the same remittance columns and source-reference fields can be requested on future batches without rewriting the instructions from scratch.

The follow-up register should be as specific as the reconciliation file. A rejected claim needs a reason, owner, due date, and next action. A plan-exhausted line is different from a support item code mismatch. A travel-rate variance is different from a missing invoice number. Lumping them into one "NDIS follow-up" bucket makes the next batch harder because the same unresolved problems keep returning without a clear decision trail.

Archive the original remittance advice, extracted working file, claim-register update, bank reconciliation evidence, and any correspondence about rejected or corrected claims. If the practice applies a seven-year retention discipline for NDIS and accounting records, the archive should let a reviewer move from the bank deposit to the remittance row, then back to the invoice and participant record without rebuilding the batch from email and portal downloads.

That is the control: every plan-manager payment is decomposed into lines, every line has a status, every status has evidence, and the batch total agrees to the bank.