Direct answer
Reconciling connected systems means comparing what each holds, on a schedule, and writing down every difference with an owner. Do it because a run that finished without an error message does not prove the two systems agree: records can be skipped, rejected or changed on one side only. The routine has four steps: pick what to compare, compare it, log each mismatch as missing, extra or changed, and decide whether to fix the record or investigate the cause. This is a business check on your data. It is not an accounting reconciliation or an audit.
Why a successful run does not prove agreement
A run can succeed while records are quietly skipped by a filter, rejected for a missing required field, or edited directly in one system afterwards. Errors you never see are still differences. Monitoring tells you a run failed; reconciliation tells you the results disagree. See automation monitoring and alerting for the first, and use this routine for the second.
What to compare
Start with a few cheap checks and add depth only where mismatches turn up:
- Record counts in each system for the same scope, such as everything created in the same period
- Totals on key numeric fields that both systems hold
- Key identifiers: which ones exist in one system and not the other
- A small sample of full records, compared field by field
Using the field-owner table
When two values differ, you need a rule for which one is right. The rule is the field-owner table from your system of record decision: for each field, one system is the source of truth and its value wins. If that table does not exist yet, the first mismatch will start an argument. Write it before you start comparing.
The mismatch log and its owner
Keep one log with a row per difference. Record the identifier, the type of difference (missing on one side, extra on one side, or a changed value), the systems involved, the date found, the person responsible and the outcome. One named person owns the log; if everyone can add rows and nobody owns it, it stops being read. The log is also your evidence of how well the integration behaves over time.
Cadence is a decision
How often to compare depends on what a mismatch costs and how quickly it compounds, not on a standard calendar. Data that drives customer contact or invoicing justifies a tighter rhythm than data used only for occasional reports. Choose a cadence, write down why, and revisit it after a change to either system. Start a bit more often than you think you need and relax it when the log stays quiet.
Fix the record or investigate the cause
A single mismatch is usually a record to fix. Repeated mismatches of the same kind point to a cause: a field mapping, a filter, a rule that rejects certain values or a manual edit habit. Note the pattern in the log and take it to whoever owns the integration. Correcting rows by hand while the cause stays unchanged only postpones the next batch. If the cause sits in a system you do not control, outside help may be needed; bring the log with you.
Making the report a small automation
Once the routine is stable, the counting and listing can be automated so a person only reviews the result. Automate the comparison and the report, not the correction: a tool that silently overwrites data on one side can turn a small mismatch into a larger one. Keep a person in the loop for any change to records.
After changes
Re-run the comparison after any change to either system: a new field, a renamed field, a new required value, a changed workflow or a new user role. These are the moments when a working integration starts to disagree. Add the new field to what you compare and update the field-owner table.
Where LATYNEX fits
If you want the comparison built into the integration, it can be included in the scope of an Automation Sprint (€1,690, fixed scope), agreed in writing before work starts. Larger or unusual integrations are scoped separately after a technical review. See Workflow Automation & Systems Integration.
Questions
Is this the same as accounting reconciliation?+
No. It is an operational check that two systems hold the same business records. It does not replace bookkeeping controls or an audit.
Which system wins when values differ?+
The system you have named as the source of truth for that field. Record this in a field-owner table before you compare.
Should mismatches be corrected automatically?+
Be cautious. Automate the comparison and the report, and keep a person reviewing changes to records, at least until the causes of mismatches are understood.
How often should we compare?+
As often as the cost of an undetected mismatch justifies. Start tighter than you think you need, then relax once the log shows few differences.
What if the same mismatch keeps appearing?+
Treat it as a cause to investigate, not a record to keep fixing. Look at field mappings, filters, rejected values and manual edits.