WRITING · ENGINEERING
Exporting a claim file is easy. Reconciling one is the job.
Most software treats claiming as an export and stops. The money question — did we get paid for what we actually delivered — starts exactly where the export ends.
Where most systems stop
Generating a claim file is a formatting exercise. Take some delivered services, write rows in the shape the payer expects, produce a file. A competent developer can do it in an afternoon, and a great many products ship exactly that and call claiming solved.
Then the file is uploaded, and reality begins. Some lines are accepted. Some are rejected for reasons expressed in the payer's vocabulary rather than yours. Payment arrives days later as a lump sum that does not obviously correspond to anything. And someone in the finance team opens a spreadsheet, because the software has quietly handed the actual work back to a human.
That spreadsheet is the tell. It means the system produced an artefact rather than completing a process.
Claiming is a loop
The shape that works treats a claim as a round trip with five stages, each of which the system owns:
- Delivery — a service happens, and becomes a billable with everything needed to justify it later.
- Pricing — the billable is priced under the rules in force on the day it was delivered.
- Validation — lines are checked before submission, against the payer's rules, while there is still time to fix them.
- Submission — a file is produced that the payer accepts.
- Reconciliation — money that arrives is matched back to the lines that produced it, and anything unmatched is visibly unmatched.
Only the fourth stage is the export. The other four are where claims are actually won or lost, and they are the ones commonly left to the provider.
Price at the time of service, not the time of billing
In the NDIS the price catalogue changes — most visibly each first of July, and at other times besides. That single fact breaks the obvious implementation, which is to look up the current price when generating the claim.
A service delivered in June and claimed in July must be priced at June's rate. A claim reissued a year later must still produce the same figure it produced originally. If your system prices at billing time, both of those are wrong, and the second is wrong in the particularly nasty way where the books no longer reconcile with what was actually paid.
The fix is unglamorous and non-negotiable: version the catalogue, record which version applied, and always price against the version in force on the service date. It also has to survive the awkward middle ground — services delivered across a boundary, and corrections to services delivered before the last change.
Validate before you submit, not after
A rejected claim file is expensive in a way that is easy to underestimate. The rejection arrives late, it explains itself in the payer's terms, and by then the provider has usually moved on to the next fortnight.
So the useful place to enforce the payer's rules is upstream, in the system, before the file exists — with the error expressed in language the provider understands and attached to the record that caused it. "This claim will be rejected because the participant's plan does not cover this support item on this date" is actionable today. The equivalent rejection code arriving next week is archaeology.
This means duplicating the payer's rules inside your system and keeping them current, which is genuine ongoing work. It is also the difference between software that submits claims and software that gets them paid.
Reconciliation is the part that pays for itself
Money comes back aggregated. The task is to decompose it: this payment covers these lines, at these amounts, leaving these differences.
Most differences are mundane — a partial payment, a rounding difference, a line paid at a rate other than the one claimed. What matters is that every one of them is either matched automatically or surfaced explicitly as unmatched. The failure mode to design against is not "we cannot match this" but "we quietly matched it wrongly and the books balance on a lie".
Done properly, the provider's month-end becomes a review of exceptions rather than a reconstruction from scratch. Done improperly, you have built a very expensive way of producing a CSV.
The evidence has to survive
Every claim is a statement that a service was delivered, and at some point somebody may ask you to prove it. That means the chain from claim line back to the delivered service, the note written about it, the worker who provided it and the plan it was funded under has to remain intact and inspectable — for years, and after staff have left.
This is where claiming and compliance stop being separate features. If the delivery record is append-only and the claim references it rather than copying from it, evidence is a query. If the claim was assembled by exporting a snapshot into a separate finance tool, evidence is a project.
The measure of success
There is a simple test for whether claiming has been built properly: can the provider close the month without opening a spreadsheet?
Not "is there a claims screen". Not "can we export a file". Can the money that arrived be explained, line by line, by the system that generated the claim — with the exceptions listed and nothing silently absorbed. If yes, the software is doing the job. If no, it produced an artefact and left the job to the provider.
Written from building this loop twice, for different jobs in the same sector — CareOp for providers and MySienna for support coordinators. The payer changes by industry; the loop does not.