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 behind NDIS plan-manager remittance extraction. The remittance is evidence for which participant ledger to update, which invoice line has been short-paid, which claim needs correction, and whether the money in the bank agrees to expected claims.

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.

This is not a general NDIS invoicing guide or a US healthcare payer EOB workflow. In the Australian plan-managed NDIS workflow, the provider has invoiced a plan manager, the plan manager has processed the claim against the participant's plan, and the provider must break the remittance back into finance records that can be posted, followed up, and retained.

The end state: every line has a paid, partial, rejected, or follow-up status; rejected items have an owner and next action; paid lines agree to the bulk EFT; and the remittance advice plus extraction file are archived for 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 or WorkCover and CTP claim payment reconciliation. 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 similar: a batch header with payer, remittance date, total amount, and EFT reference, followed by lines grouped by participant or invoice. My Plan Manager and other plan managers may present support item codes, service dates, quantities, rates, paid amounts, rejected amounts, and status messages differently, but the reconciliation question is the same: which original invoice line did this payment or rejection belong to?

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. Source file and page references matter when a rejected line needs to be queried weeks later and the bookkeeper has to prove exactly what the plan manager returned.

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 ask for one row per remittance line and preserve the source file and page for every extracted item.

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, 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. Reviewers should be able to 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. Archive the original remittance advice, extracted working file, claim-register update, bank reconciliation evidence, and any correspondence about rejected or corrected claims so the practice can move from the bank deposit to the remittance row, then back to the invoice and participant record.