Compare two systems at different cut-offs and you will find differences. Most of them won't be real.

They look real. A record exists on one side and not the other. A balance is off by the value of a handful of transactions. Someone raises a break, someone else spends a morning chasing it, and the answer turns out to be "it was taken at a different time".

The fix is simple and easy to skip: take both sides at the same cut-off, and write that cut-off down.

Why timing differences look like missing records

A reconciliation compares two snapshots. If the snapshots were taken at different moments, anything that happened between those moments shows up as a difference. The comparison can't tell a timing gap from a lost record. Both look like "present on one side, missing on the other".

Here are the usual causes.

The 23:58 payment

A payment is posted at 23:58 on the last day of the month. One system books it in that day's period. The other system receives it after its overnight batch has started and books it the next day. Both systems are right by their own rules. Compared by period, one side shows the payment and the other doesn't.

Late journals, accruals and reversals

Period-end is when journals arrive late, accruals are posted and then reversed on day one of the next period. If one extract is taken before the late journals and the other after, the balances differ by exactly those journals. If an accrual is captured on one side and its reversal on the other, you get two differences that cancel out in reality but not in your report.

Time zones: UTC against local time

If one system stamps transactions in UK time and the other in UTC, the same cut-off can sit an hour apart for more than half the year. During British Summer Time, midnight in London is 23:00 UTC. Everything posted in that hour lands in different days on each side.

It's easy to miss because it only shows up in part of the year, and only for transactions near midnight. Write the time zone next to the cut-off time, for both extracts.

Batch run times

Many systems don't update in real time. A nightly batch finishes at 02:00 one night and 04:30 the next. An extract taken at 03:00 includes the batch on one day and not on the other. If the two systems batch at different times, an extract taken at "the same time" still isn't the same cut-off.

What to agree and write down before the comparison

Agree these before anyone runs a comparison, and put them in writing:

  • The cut-off for each dataset. Date, time and time zone. For example: "Source: business date 30 September, extract after the end-of-day batch completes, UK time. Target: same business date, UTC timestamps converted to UK time before comparing."
  • Which side's extract time is the baseline. One side defines the cut-off. The other side is taken to match it.
  • How transactions in flight are treated. Payments sent but not received, journals posted after the cut-off for the period, accruals and their reversals. Decide which period each belongs to.
  • Who confirms both extracts were taken at that point. A named person checks the batch logs or extract times and says so in writing.

Store this with the comparison results, so anyone reading them later knows exactly what was compared.

Label timing differences as expected, not as breaks

Even with an agreed cut-off, some timing differences remain. That's fine. What matters is how they are labelled.

Treat them as expected differences, with a rule. For example: "Transactions timestamped between 23:00 and 00:00 UTC on the cut-off date may fall in the next business day on the target side. Expected. Reviewed by the finance systems lead." Each matching difference gets that label and a reason, and drops out of the break count.

Anything that doesn't fit a written rule stays a break and goes to a named owner.

This is box 3 of the five sign-off questions: the expected differences, and why. The full set is in Most migrations don't fail on load day: 5 questions to answer before sign-off.

The order matters. Write the rule first, then run the comparison. A rule written after you've seen the differences looks like an excuse, and the person signing off will treat it like one.

The same applies in business as usual

When you change a pipeline and compare yesterday's output with today's, align the cut-off first. Run both versions against the same input, as at the same business date. Otherwise the new data that arrived overnight will look like a change in the pipeline, and you'll chase differences your change didn't cause.

In short

Timing differences can be explained. But only against a cut-off everyone agreed beforehand.

Same cut-off, both sides, written down, with the time zone next to it.