Two systems, two different business facts
When we modernized an enterprise data warehouse and moved it to a cloud data platform, we ran old and new side by side and reconciled them until finance signed off. The lesson that stuck: most differences were not errors. They were timing, scope and matching rules nobody had written down. Reconciling CRM and ERP revenue with an AI assistant is the same work, and it fails for the same reason when those rules stay implicit.
A CRM opportunity and an ERP transaction are not two copies of one fact. They describe different stages of a commercial process, with different owners and clocks. One opportunity can produce several orders, orders get amended, and recognized revenue can land after booking or invoicing. In the high-technology companies we work with, running Salesforce for the front office and NetSuite or Oracle for the ledger, this is the gap the CFO and the head of sales debate every quarter.
Name the comparison precisely
Is the team comparing pipeline with bookings, orders with invoices, or invoices with recognized revenue? Each needs a different population and timing model. Calling all of them revenue reconciliation hides the disagreement the assistant is supposed to explain.
Have finance and sales operations approve the comparison together. A technically valid join is not enough if the teams mean different things by period or amount. The objective is a shared explanation of the gap, not forced equality between measures that should legitimately differ.
Write the comparison down as a single sentence both leaders sign, such as invoiced amounts in the reporting currency compared with closed-won opportunity amounts for the same quarter. It sounds trivial. In my experience it removes half the arguments before the assistant answers its first question, and it gives reviewers a fixed reference when a later answer looks wrong.
Write the matching rule down
Identify the stable identifiers that connect records across systems. Account names are not enough: names change, subsidiaries share labels, duplicates exist. Document accepted identifiers and how missing or ambiguous matches are treated, and never let the assistant silently pick a likely-looking record. This is master data management work, and no model substitutes for it.
Test one-to-many relationships. If the evaluation only contains one-to-one records, a clean demonstration hides the errors that matter most. Include cancellations, credits and partial fulfillment wherever they affect the comparison.
Create an explicit unmatched category. Unmatched records are not necessarily errors; they need an explanation and an owner. Dropping them to make totals look cleaner defeats the purpose of reconciliation.
Make timing and currency visible
State the date used on each side: expected close, booking, invoice or recognition period. A transaction near a period boundary can explain a large gap with no business problem behind it.
Agree source cutoffs and refresh schedules. A CRM update made after the ERP snapshot produces a temporary mismatch, and the user should be able to tell a timing limitation from a real commercial discrepancy. Label unaligned comparisons as such.
Keep currency explicit. Source amounts, reporting currency and rate dates all move the result. Finance defines the treatment for the pilot. An assistant should never choose an exchange-rate assumption simply to finish a calculation when the decision requires an approved policy.
Judge the explanation, not just the total
Bank examiners taught me to value one kind of answer: show me, for this customer on this day, why these two numbers differ. A strong reconciliation output partitions the gap into categories the business recognizes, such as timing, scope, amendments, unmatched records and open questions, each backed by traceable records. A plausible narrative without evidence is harder to catch than an arithmetic error.
Have reviewers inspect matched and unmatched examples, and record how long validation takes. A polished narrative that recreates the original manual effort has little operational value. Keep the comparison at the agreed grain, because rolling order-level detail up to customer totals can hide exactly the relationships the question was about.
Give each unmatched category a resolution owner and retain the eventual explanation alongside the original result. At the pilot review, show which differences the assistant explained correctly, which still needed investigation and how much work remained with finance. I would report those results directly. A clearer reconciliation is useful on its own; it does not need to be presented as autonomous accounting judgment.