Blog · AutoRecon
Why reconciliation software should be read-only by default.
A reconciliation system needs to see everything. That is not the same as needing to change anything, and the difference should shape how you deploy it.
When finance and operations teams evaluate reconciliation software, the conversation tends to focus on match rates, rule engines and dashboards. The question of what the system is allowed to touch often comes up late, sometimes in the security review just before go-live. We think it should be one of the first questions, and the answer should almost always start with “nothing”.
Seeing everything is not changing anything
To reconcile, a system needs a lot of data: switch and network files, core and GL extracts, bank and MT statements, ERP records. Its job is to compare them, explain differences and report. None of that requires writing to the core banking system, the GL or the ERP.
Yet integrations are often built with broad credentials because it is quicker, and “we will lock it down later” rarely happens. A tool whose job is to check your books should not be able to alter them by default.
Why it matters more than it seems
- It narrows the blast radius. A misconfigured rule in a read-only system produces a wrong report that someone can catch. In a system that can post entries, it produces wrong books.
- It keeps the control independent. Reconciliation is a check on other systems. A check that can modify what it is checking is a weaker control.
- It makes approvals easier. Information security, internal audit and IT can approve read access to files and extracts far more quickly than write access to core systems.
- It makes the trial honest. You can run the new system next to the existing process without either interfering with the other.
Run in parallel before you switch
Read-only by default makes a parallel run straightforward, and we think every reconciliation change should have one. The new system ingests the same files and produces its own matches and breaks; the team keeps closing the old way. Each day, compare the two:
| Compare | What you learn |
|---|---|
| Match rate | Whether the rules cover what the team already matches |
| Breaks found by one side only | Missing rules, or real issues the old process missed |
| Rejected rows and reasons | Data quality problems in the source files |
| Time to close | Whether the daily close is realistic |
Only when the differences are understood does the new system become primary. If you need a way to frame the numbers, our match rate and break ageing calculator helps set the baseline.
When to open a write path, and how
Some teams eventually want the system to do more: post an adjusting entry, update a status, file a return. That can be reasonable. The principles we would apply:
- Open one path at a time, for a specific, named purpose.
- Keep a maker and checker on every action that writes.
- Record every write in the same audit log as the matches.
- Keep regulatory submissions behind a checker, always.
For the policy and regulatory aspects of system access in your institution, confirm with your information security and compliance advisers.
How we built it
AutoRecon is read-only by default: it reads your files and systems and writes nothing to your core unless you open the path. Files and APIs are ingested as they land, mapped to one schema with bad rows rejected and the reason given, and matched on rules you write. A new recon goes live in parallel first, then becomes primary. The daily close is approved by maker and checker, returns are drafted with a checker before submission, and it can run on managed cloud, in your own VPC or on-premises. For a broader view of the move away from spreadsheets, see spreadsheet vs automated reconciliation, and the rest of the AutoRecon guides.
Questions
Does reconciliation software need write access to core banking?
Not to reconcile. It needs to read files and extracts from switch, core, GL, statements and ERP. Write access should be opened only for a specific purpose, with maker-checker.
What is a parallel run in reconciliation?
Running the new system on the same files alongside the existing process, comparing match rates, breaks and close times daily before making it primary.
Why is read-only access safer for reconciliation?
It limits the damage a misconfigured rule can do, keeps the reconciliation independent of the systems it checks and makes security approvals simpler.
See it on your own data. AutoRecon — Close the day before it starts. Book a 30-minute working session with an engineer.