Deterministic checks find the gaps. AI helps people understand them.Last quarter's revenue was $14.6 million. Or $14.2 million. Or $14.1 million. The ledger says one thing. The Lakehouse table feeding your BI says another. The dashboard the board looked at this morning says a third.None of the three numbers is obviously wrong, and that is the problem. When the same metric lives in several systems, each with its own refresh schedule, transformations and quirks, the numbers drift apart. Reconciliation is the work of finding where they disagree and deciding which one, if any, you trust. Done by hand, it is slow, it misses things, and it scales badly as you add systems.I split the job in two. Deterministic checks establish the facts: row counts, sums, join-key coverage. AI handles triage and explanation. It learns which differences are normal, ranks the ones that are not, and drafts a plain-language account of what probably happened. The checks give you the truth. The AI makes it something a person can act on.Start with checks that cannot lieBefore any model gets involved, you need checks that are plain arithmetic. For every metric you reconcile, run the same small battery of comparisons:Row counts per tableSums of the measures that matterJoin-key coverage, so no business key silently vanishesHash comparisons on a sample of rows, to catch silent corruptionRun them on a schedule. The output is a table of differences with no interpretation. Nothing here needs AI, and that is deliberate. When an engineer asks why a dashboard changed overnight, the first answer should come from a check that can be re-run and gives the same result every time.The noise problemThe trouble with deterministic checks is volume, not accuracy. On a real pipeline they fire constantly, and most of what they flag is expected:Time zone cutoffs make one feed's Fridays look short.Late-arriving rows land after the extract ran.Currency rounding shaves fractions off totals.Two teams define revenue differently, gross versus net, and nobody wrote it down.A dashboard cache lags the Lakehouse by an hour.A human reviewer has to learn all of this, and the knowledge lives in people's heads. Two reviewers disagree on what is worth chasing. Context switching eats hours, and the checks keep firing either way.Let the model learn what normal looks likeThis is where AI earns its place. Feed it the history of past reconciliations, meaning every flagged difference and how it was resolved. Two things happen:Baselines per check. A statistical baseline of normal variance for each check tells you that a half-percent gap the morning after a load is routine, while the same gap on a different feed is not.Explanations from history. An LLM gets the current difference plus the closest entries from the resolution log and drafts a short explanation with the evidence attached.Differences that match a known pattern get labeled and logged instead of escalated. The rest are ranked by dollar impact, how new the pattern is, and whether it is getting worse.Reviewers notice the next part most. Instead of a row reading TABLE_A.SALES_TOTAL != TABLE_B.SALES_TOTAL, they get a sentence saying what probably happened and why. Nobody has to decode column names before the coffee kicks in.A worked example Go back to the three figures at the top: ledger $14.6M, lakehouse $14.2M, dashboard $14.1M. The deterministic check compares order counts and revenue per fulfillment center between the source system and the lakehouse table:SELECT COALESCE(s.center, l.center) AS center, COALESCE(s.orders, 0) AS source_orders, COALESCE(l.orders, 0) AS lakehouse_orders, COALESCE(s.orders, 0) - COALESCE(l.orders, 0) AS order_gap, COALESCE(s.revenue, 0) - COALESCE(l.revenue, 0) AS revenue_gapFROM (SELECT center, COUNT(*) AS orders, SUM(amount) AS revenue FROM source.orders WHERE order_date >= '2026-07-01' AND order_date < '2026-10-01' GROUP BY center) sFULL OUTER JOIN (SELECT center, COUNT(*) AS orders, SUM(amount) AS revenue FROM lakehouse.orders WHERE order_date >= '2026-07-01' AND order_date < '2026-10-01' GROUP BY center) l ON s.center = l.centerWHERE COALESCE(s.orders, 0) COALESCE(l.orders, 0) OR COALESCE(s.revenue, 0) COALESCE(l.revenue, 0);It returns one row and says nothing about why:centersource_orderslakehouse_ordersorder_gaprevenue_gapOH-0148,31036,31012,000412,000The AI layer takes that row and the resolution log. The log shows OH-01 had the same gap on two earlier closes, both traced to the 2 a.m. extract. It drafts this:OH-01 is missing about 12,000 orders (~$412K) in the lakehouse. The source extract ran at 2 a.m., before the late-day batch landed. This matches two earlier closes. Likely cause: extract timing, not data loss. Confidence: medium. Attached: row counts, extract timestamps, and the two prior resolutions.A reviewer re-runs the extract, the gap closes, and the log records the cause as late_arriving_rows. That explains the $0.4M gap between the ledger and the lakehouse. The dashboard's remaining $0.1M is cache lag, a known pattern, so the model labels it and logs it without escalating.Putting it togetherThis is the order that works:Name the reconciliation points. For every metric that matters, write down the source system, the lakehouse table and the report. If you cannot name all three, start there.Write the deterministic checks first. Row counts, sums, join-key coverage and hash sampling. Run them on every load, not once a month.Keep a structured resolution log. Every flagged difference gets a row: what it was, its cause category, how it resolved and who closed it. This log is the training data for everything that follows.Add the AI layer on top. Variance baselines, prioritization and plain-language explanations.Keep people on the exceptions. Route anything the model cannot explain confidently to a reviewer, with the raw numbers attached. The model drafts and a person signs off.Tradeoffs and where it goes wrongExplanations can sound confident and be wrong: A model can invent a plausible cause for a difference it does not understand. Treat every explanation as a draft attached to evidence and keep the raw check data one click away.The model learns your mistakes. If reviewers wrongly closed a real break as normal, the model will suppress it next time. Spot-check a sample of auto-labeled "normal" differences on a regular schedule.The log is only as good as the discipline behind it. If reviewers close differences with notes like "looked fine", the model learns nothing. Use cause categories instead of free text.It has a cost. The AI layer adds compute, latency and something else to maintain. Small pipelines may not need it. If your checks fire five times a week, a person with a spreadsheet will do better. The layer pays off when the volume of noise exceeds what the team can read.Keep an audit trail of dismissed differences. When the CFO asks why a flagged gap was closed, "the model said it was normal" has to come with the evidence attached.From fire drill to background processMonth-end reconciliation is a fire drill because differences are found late and investigated from scratch. With this setup, the checks run on every load, the noise is filtered and real breaks arrive with a draft explanation. Finance spends less time waiting on the close and more time on the breaks that matter.Pick one metric this week. Write the deterministic checks and start the resolution log. The AI layer can wait until the log has a few months of history. Truth first, explanation second.