A bulk payment request is not one claim. It is a list of lines, and each line makes a set of assertions: this participant, this support item, this date, this quantity, this price, under this plan. The NDIA validates the assertions line by line, which means a file does not fail as a whole — individual lines do.
That is worth internalising, because it changes where the work goes. Almost every rejected line was checkable before the file was written. The mechanics below are the ones that catch providers most often.
Where lines actually fail
Rejections cluster around a small set of mismatches between what a line asserts and what the NDIA holds:
- The support item is not in the participant's plan for the date claimed
- The plan changed — expired, replaced or varied — partway through the claim period
- The claimed price exceeds the cap in the pricing arrangements in force on that date
- The line duplicates one already claimed, sometimes from a previous file
- The claim or cancellation type does not match how the service was actually delivered
Why a rejection costs more than a resubmission
The rejection arrives after the claim period has closed. By then the roster has moved on, the coordinator who made the call may be on leave, and the context that made the line make sense has evaporated. Unpicking one bad file means re-deriving decisions that were obvious a fortnight ago.
There is a cash-flow cost too. A rejected line is revenue you have already paid wages against, now waiting on a second round trip.
Pre-check lines before the file exists
The fix is structural, not heroic. Validate every line against the participant's current plan and a date-effective price book at the moment the line is created — not at export. A price book that knows which rates applied on which dates catches the mid-period price change that a static spreadsheet cannot.
- Every line's support item appears in the participant's plan on the service date
- Every price is at or under the cap that applied on that date
- No line duplicates an earlier claim, in this file or a previous one
- Plan end dates inside the claim period are treated as boundaries, not ignored
Fix problems as a list, not a mystery
When a pre-check fails, the output should be the specific lines and the specific reasons — not a single refusal to export. A named problem is a ten-minute fix. An unnamed one is an afternoon.
Nexrosta checks every line against the plan and the date-effective price book before a file is written, lists blocking issues individually, and flags invoices that have already been claimed before you claim twice. Files reproduce byte-for-byte later, so what you sent is provable at audit.