The auditor wants to see your reconciliation. Your evidence is one word: "passed".

That's a common position to be in, and it's not because anyone was lazy. The reconciliation probably was done. Someone ran it, looked at the result and ticked the box. But "reconciled" isn't evidence. It's a word in a status report. Six months later, nobody can tell what it meant.

Before I'd put my name on a sign-off, I want to see 4 things.

1. What was compared

Which files or tables, from which systems, at which cut-off, matched on which keys. This is the scope of the check. Without it, "passed" could mean anything from "every field of every record" to "the row counts were close".

It also tells you what wasn't compared. If the check covered customers and balances but not transactions, that's useful to know before go-live, not after.

2. The rules

How columns were mapped from old to new. What tolerance was allowed on amounts. How dates, blanks and text were normalised. What counted as a match.

The rules matter because two people can run "the same reconciliation" and get different answers. A tolerance of a penny and a tolerance of a pound give very different break lists. If the rules aren't written down, the result can't be rerun, and a result that can't be rerun can't be defended.

3. What was found

Every break, with a reason. Each one is either expected (a known transformation, a timing difference, a deliberate fix), fixed (and rechecked), or still open (with an owner and a decision about whether it blocks go-live).

A short break list with reasons is far more convincing than "0 breaks". Zero breaks on a real migration usually means the check wasn't strict enough, not that the data was perfect.

4. Where we're unsure

The fields nobody checked. The data that couldn't be compared because the old system didn't hold it in a usable form. The assumptions the team made and didn't verify.

Number 4 is the one teams skip. It feels like admitting weakness in a document that's meant to give confidence. But it's also the one that makes the other three believable. A sign-off pack that admits two known gaps reads as honest. One that claims full coverage reads as untested, and an experienced auditor knows the difference.

Why this matters beyond the audit

The audit is the obvious reason, but not the most important one. The real value comes three months after go-live, when someone finds a number that looks wrong. With evidence, you can answer quickly: was it in scope? Was it a known break? Was it covered by a tolerance? Without it, you're reconstructing a project from memory and old chat messages, usually under pressure.

It also changes the conversation at sign-off. Instead of "has this been reconciled?" and a yes or no answer, the person signing can see what they're signing for and decide whether the open items are acceptable. That's a better decision, and a fairer one for the person making it.

How much is enough?

This doesn't need to be a 50-page document. For most changes, one page covers it: a short scope, a list of rules, a break summary with reasons and a short list of known gaps. The important thing is that it exists, it's specific, and someone else could rerun the check from it.

The trade-off is time. Writing this down takes a few hours on a big migration. But most of the information already exists in the heads of the people who did the work. The effort is in capturing it before they move on to the next project.

In short

  • What was compared: sources, cut-off, keys.
  • The rules: mapping, tolerances, matching.
  • What was found: every break with a reason.
  • Where you're unsure: written down, not hidden.

When you sign off a migration or a report change, what do you actually get to see?