How to reconcile records between two systems with an AI agent

Decide which system is authoritative for each field, then let the agent extract both at one moment, match on a stable key, classify every break and propose a fix with evidence. Routine field breaks in the non-authoritative system can be corrected at depth 3 once certified. Structural breaks and sign-off stay with the reconciliation owner.

What does reconciling two systems mean, and who owns it?

Most firms hold the same facts in more than one place. A customer's address sits in the CRM and the core banking system. An employee's grade sits in the HRIS and the payroll system. A policy's premium sits in the policy administration system and the billing system. Interfaces are meant to keep them aligned, and they drift: a failed update, a manual change in one place, a migration that missed records.

A reconciliation compares the two, lists the differences, explains them and fixes them. The reconciliation owner, usually in operations or finance, owns the process and signs it off. The owner of each system owns its data. A data governance function, where one exists, decides which system is authoritative.

What are the steps, and who acts at each?

1. Data owner: names the authoritative system for each field. The address in the core banking system may be authoritative for statements, while the CRM is authoritative for marketing preferences. Without this, every break is an argument.
2. Reconciliation owner: defines the matching key and the fields in scope. The key must be stable in both systems, such as a customer number, not a name.
3. Agent, depth 1: extracts both systems at the same point in time. Extractions minutes apart create false breaks for records that changed in between.
4. Agent, depth 1: matches records on the key, and lists records present in only one system.
5. Agent, depth 1: classifies each break: missing in one system, field mismatch, format difference only (such as "Rd" against "Road"), or timing difference that will clear on the next interface run.
6. Agent, depth 3: clears format-only differences and confirms timing differences on the next run. These are recorded, not corrected.
7. Agent, depth 2: proposes a fix for each real break, naming the authoritative value, its source and the record to change.
8. Agent, depth 3: applies routine fixes to the non-authoritative system, for field types certified at that depth, with a before and after record.
9. Agent, depth 1: flags structural breaks: a block of missing records, a field that disagrees on every record, a key that has stopped matching. These point to a failed interface or a migration error.
10. Reconciliation owner: reviews the results and signs off, including any breaks carried forward.

Why does the agent never fix the authoritative system?

Because that turns a reconciliation into an overwrite. If the payroll system says an employee's grade is 5 and the HRIS says 4, and HR is authoritative for grades, the fix is to change payroll. Changing the HRIS to match payroll would make the wrong value permanent in the place everyone trusts. When the authoritative system itself looks wrong, the break goes to its data owner. The HRIS case is covered in updating employee records in your HRIS, where the same field-level care applies.

What if one system is old?

Many reconciliations involve a system without a modern interface. The agent may need to work from a scheduled file or a screen extract. That is workable, as discussed in whether AI agents can work with legacy systems, but it changes the timing: the extraction from the old system fixes the point in time, and the agent should match the other system to it. The broader patterns for read and write access are in how to connect an AI agent to your systems.

How is this different from a two-way match?

A two-way match compares two documents for one transaction, such as an invoice and a purchase order, to decide whether to pay. A reconciliation compares whole populations of records to find where systems disagree. The matching logic is similar; the purpose and the owner differ. A failed two-way match blocks a payment. A reconciliation break is a data quality issue to be fixed at source, and recurring breaks in customer data are best handled through fixing data quality issues in customer records.

What should you measure?

• Breaks by class, each run. Format and timing breaks should be stable; real breaks should fall.
• Age of open breaks. A break carried forward for weeks is a decision someone is avoiding.
• Recurrence: the same record breaking again after a fix shows the interface, not the record, is the problem.
• Fixes reversed after the agent applied them.
• Structural breaks found, and time to root cause.

Which controls leave evidence?

Authority per field, written down. Evidence: the authority map version used for each run.

Same-moment extraction. Evidence: extraction times for both systems.

Before and after on every fix. Evidence: the record of each change and its source.

Sign-off by a named person. Evidence: the signed summary with carried-forward breaks listed.

Where does it usually go wrong?

No authority map. Teams start reconciling and argue about every break. Write the map first.

The agent fixes the symptom. It corrects a thousand addresses every week, and no one asks why the interface keeps failing. Structural flags must reach someone who can fix the interface.

Matching on names. Names change and are spelled differently. Matching on them creates false breaks and, worse, false matches.

Sign-off becomes routine. The owner signs a summary with the same carried-forward breaks every week. Report break age prominently so this cannot go unnoticed. Certify the fix capability on real past breaks before depth 3, per train, shadow, certify, widen.