A reconciliation software audit trail must log every event that shaped the result: which statement was uploaded and by whom, every edit to an extracted value, every match the tool or a person made, every override of a rule, and every sign-off. Each entry needs a named user, a time and the before and after values.
What must a reconciliation software audit trail log?
A reconciliation software audit trail is a time-ordered record of the actions that produced a reconciliation. It must log enough for a reviewer who was not present to rebuild what happened: what came in, what the tool did with it, what people changed, and who approved the final result.
Events and the fields each must capture
The table lists the events that belong in the trail. The fields are the minimum for each.
| Event | Fields to capture |
|---|---|
| Statement uploaded | User, time, file name, file fingerprint, account, period |
| Values extracted | Statement, line count, any field read with low confidence |
| Value edited | User, time, line, field, old value, new value, reason |
| Automatic match | Pair of lines, rule that matched them, time |
| Manual match or unmatch | User, time, lines, reason |
| Rule override | User, time, rule bypassed, item affected, reason |
| Item written off or adjusted | User, time, amount, account, approver |
| Prepared | User, time, state of the report at that moment |
| Reviewed and signed | Reviewer, time, report version signed |
| Reopened after sign-off | User, time, reason, sign-off cleared |
Entries the trail must never allow
The trail is only evidence if it is complete and fixed. Entries should not be editable or deletable by users, including administrators. Shared logins defeat it, because the "user" field then names a team, not a person. And a trail that records only the final state of each line, rather than each change, is a snapshot, not a trail.
Uploads and source files in a reconciliation audit trail
The upload entry is the anchor of the audit trail. It ties every later number back to one specific source file: the bank statement as received. Without it, a reviewer cannot tell whether a reconciliation was built from the bank's statement, a client's re-typed copy or a file someone altered before uploading.
What makes an upload entry useful
A file fingerprint, often a hash, is a short code calculated from the file's contents. If the file changes by a single character, the fingerprint changes. Logging it at upload lets a reviewer confirm later that the stored statement is the one the work used. The entry should also keep the original file itself, not only the extracted data, so a reviewer can open the page a number came from.
Low-confidence values
Some extracted values are less certain than others, usually because of a poor scan. The trail should note which values the tool read with low confidence, so a reviewer knows where to look first. The idea of a reconciliation confidence score for each extracted field explains how those scores are produced and used.
Manual overrides and forced matches in the audit trail
A manual override is any action where a person tells the tool to accept something its rules would not. Examples are pairing two lines with different amounts, marking a flagged duplicate as genuine, or closing a difference. Overrides are often correct. Without a full trail entry, though, an override is indistinguishable from a plug.
What an override entry must show
Every override needs four things: who did it, when, what rule it bypassed and why. "Why" should be a sentence, not a code. "Vendor refunded 12.40 fee on 4 April statement" lets a reviewer check the next statement. "Adjusted" does not.
The mistake to avoid
The common mistake is letting a single person override and approve their own override. A preparer who forces a match should not be the one who signs off the reconciliation containing it. Software can enforce that, by sending any reconciliation with overrides to a second reviewer. Small teams sometimes skip this because they have only one or two people; the guide to reconciliation software for small business looks at what a small team can realistically separate.
How does a reviewer use the reconciliation audit trail to rely on the work?
A reviewer uses the reconciliation audit trail to decide how much of the work to re-perform. A clean trail, where values were extracted, matched by rule and left untouched, supports reliance with light testing. A trail full of edits and overrides tells the reviewer exactly which items to examine before signing.
A reading order for reviewers
- Check the upload. Confirm the statement covers the right account and period, and that the file fingerprint matches the stored copy.
- Check that the statement foots. Opening balance plus activity must equal the closing balance, before any edits.
- List the edits. Every changed amount or date, with its reason, compared against the source page.
- List the overrides. Each forced match or accepted duplicate, with its reason.
- Check the sign-off sequence. Preparer and reviewer are different people, and nothing changed after sign-off without reopening it.
Year end raises the stakes
At year end the reconciliation supports a balance in the financial statements, so the trail may be read by an outside auditor months later. Entries that seemed obvious in January are a puzzle by April. The year-end bank reconciliation guide covers what else that reconciliation must hold.
What to look for in a tool
Ask a vendor to show the trail for a reconciliation with an edit, an override and a reopened sign-off. The checks a tool should run on each statement before anyone edits it are listed in bank reconciliation software that proves every statement. PreciseBankFlow's Team plan lists a log of every edit to the extract along with reviewer sign-off; because it is in early access, compare what the log shows with the table above. The plans are on the PreciseBankFlow homepage.