Maker-Checker and Audit Trails When Claim Data Is Imported

When claim data is imported rather than keyed, controls move upstream. The questions become: which file was loaded, by whom, covering what period; what was rejected; what changed after loading; and who approved the settlement that followed. An audit trail that answers those is what makes imported data auditable.

Step	What the audit trail must record	The question it answers later
File received	Source, who loaded it, when, period covered	"Where did this data come from?"
Validation result	Rows accepted and rejected, with reasons	"What was excluded, and why?"
Corrections after import	What changed, by whom, why	"Was the data altered after loading?"
Claim calculated	Which scheme version was applied	"Were the right terms used?"
Approval	Maker, checker, timestamps	"Who authorised this?"
Settlement issued	Document reference	"What was actually paid?"
Reversal or clawback	Trigger and link to the original	"Was anything undone, and against what?"

Why imported data needs different controls

When a clerk keys a claim by hand, the control is at the keyboard: the person entering the data sees each figure, and a checker can review the entry against source documents. Imported data breaks that assumption. Nobody keyed the figures; a file arrived and became hundreds or thousands of claim lines at once. The old control — reviewing entries as they are made — has nothing to attach to.

So the control moves to the boundary. The questions that matter are no longer "was each figure typed correctly" but "was the right file loaded, completely, for the right period, and has it been changed since?" Completeness (did the whole period arrive, or did a truncated file load silently), source (is this the file we think it is), and immutability after load (has anything been quietly edited) become the controls that matter. An imported-data process without those is not faster than a keyed one — it is faster and unaudited, which is worse.

Segregation of duties in a claims workflow

One principle underpins the rest: the person who prepares a claim or loads its data must not be the person who approves the settlement, and the payee must never approve their own claim.

The reason is the same whether the risk is error or manipulation. A single person who can both assemble a claim and authorise its payment has no independent check between a mistake and money going out — or between a deliberate over-claim and its payment. Splitting the roles inserts an independent judgement at the point where money is committed. In a claims context this usually means the operations or finance team loads and prepares, a checker with delegated authority validates and approves by value band, and the counterparty receiving the money is nowhere in that chain. It is the same maker-checker discipline a clean claim settlement process already assumes, extended to the point where data enters the system.

What auditors ask for

The test an auditor applies is simple to state and unforgiving: reconstruct one settlement, end to end. Pick a payment; show the file it came from, the scheme version applied, the calculation, the approvals with names and times, and the settlement document. If every link is present, the settlement is supported. If any link is missing — the source file can't be produced, the scheme version in force isn't recorded, the approval has no name against it — the settlement is unsupported, regardless of whether the number was right.

Designing for that test in advance is far cheaper than assembling it retrospectively under audit. The documentation discipline behind scheme settlements exists for exactly this reason.

Corrections and restatements

Data gets corrected — a mis-keyed figure at source, a late adjustment, a restated file from a distributor. The control is not to prevent corrections but to record them as events rather than silent edits.

A silent overwrite destroys auditability: the record now shows a value that was never actually loaded, and there is no trace of what it replaced or why. A recorded correction — what changed, who changed it, when, and why — preserves the history. It also protects the person making a legitimate correction, because their reasoning is on the record rather than looking, in hindsight, like tampering. Every correction is a new line in the trail, not an erasure of an old one.

How this works in practice

A claims workflow enforces these controls structurally rather than relying on procedure. ClaimDS records the source file, who loaded it, the period and the accepted-versus-rejected split at import; applies the versioned scheme terms in force for the claim; enforces maker-checker so the preparer cannot self-approve; issues the settlement linked to the claim; and records corrections and reversals as new events in a tamper-evident audit log rather than overwriting history — so a single settlement can be reconstructed end to end on demand. The wider data-movement picture is in connected claims.

To see an imported-data settlement traced end to end, book a demo.

Note: General information describing good practice, not a statement that any particular standard or law requires a specific control. Where a compliance obligation is in question, confirm it with your auditor.