Guide
A copy is only useful if you know what is in it. This page sets out a repeatable check a finance team can run against any copy of ledger data, whoever holds it.
A ledger copy is complete when its per-object-group record counts match the source for the same date boundary, attachment shortfalls are logged as exceptions rather than ignored, and a spot check against one source report confirms the numbers. A green status alone confirms nothing has crashed — it does not confirm what was copied.
A green "success" state on a copy or a sync tool usually means one thing: the job did not crash. It says the process reached its end without an unhandled error. It does not say which object groups were in scope for that run, how many records each group held, or whether the count for any group moved compared with the last time it ran.
A run can finish cleanly and still be incomplete in a way that never surfaces as a failure — a permission scope that quietly excludes one object group, an attachment that the source reports as present but never actually serves, or a date filter that leaves out the last week of a period without raising any error at all. None of those conditions stops a job from finishing, because a vendor's own success indicator checks whether its own process completed, not what it produced. Confirming what a copy actually holds means checking the copy against the source, not checking the copy against itself.
The procedure below is that check. It works on any copy of ledger data, produced by any tool, because it starts from the source platform's own numbers rather than from a status the copying tool reports about itself.
Procedure
Six steps, run in this order. Each step depends on the one before it, so skipping ahead tends to produce a comparison that looks clean but is not.
Write down the categories your copy is supposed to hold before you look at any number. Most ledger data falls into a small set of groups — accounts, transactions, contacts, attachments — and your own close process already tells you which of those matter. A count means nothing until you know what it is meant to be a count of.
Go to the source platform and pull a record count for each object group on your list, as close to your copy's date boundary as the source allows. Use the source's own reporting or list view, not a number remembered from last time. This is the number the copy has to be checked against, so it has to come from the source itself, dated.
Set the copy's count for each object group beside the source count for the same group and the same period. Do this group by group rather than as one combined total, because a shortfall in one group can hide inside a surplus in another when the two are added together.
Attached files lag behind the records they belong to more often than any other object group, because a source platform can report a file as attached before it finishes indexing or serving it. A file count that is short of the source is not evidence of a working copy with a rounding error — it is an exception, and it belongs on the list of things to check next time, not in a rounding margin.
Decide, before you compare anything, whether you are checking an as-at count (everything as of a moment) or a period count (everything created or changed within a range), and confirm the source report you pull is stated the same way. Most count mismatches that survive the first four steps turn out to be two correct numbers answering two different questions.
Pick one report the source platform already produces — a trial balance, an aging report, a transaction list for a short date range — and manually trace a handful of its line items into the copy. A count that matches can still be a count of the wrong records; tracing individual entries is what catches that.
Reading the result
The six steps above will not always produce a perfect match, and they are not supposed to. The question that matters is whether a gap has a stated, source-dependent cause, or whether it does not.
Read how exceptions are named, retried, and kept visible across runs
Cadence
Run it once in full before you rely on a copy for anything, so you have a baseline rather than an assumption. After that, three triggers matter more than a fixed calendar interval.
The alternative to doing this by hand
Everything the six steps above reconstruct by hand is what a properly specified run report should already state on its own: the source it read from, the date and time it finished, the object groups it covered, the record count per group, the exceptions it raised, and the outcome of the run itself. A report that carries all six of those fields turns this procedure from a manual reconciliation into a read.
That is the specification a dated run report is built to. Reading it does not remove the value of running the full check periodically as a second, independent confirmation — but it means you are not reconstructing the source counts and the date boundary from scratch every time.
See how a run works and what its report specifies, field by field
Common questions
Almost all of it goes to two steps: step two, pulling a count for each object group out of the source, and step six, tracing a handful of line items by hand. The other four steps are decisions rather than work. The check does not get faster with practice so much as it gets faster once you know where each source report lives, which is worth writing down the first time you find them.
Stop at the object group where the disagreement appears and re-check steps four and five for that group specifically: confirm the date boundary matches on both sides, and check whether the gap is concentrated in attachments rather than spread evenly across record types. If the gap survives both checks, treat it as an exception rather than guessing at a cause — record the group, the count, and the date, and raise it with whoever operates the copy.
No. Every step in this procedure reads from the source and reads from the copy; nothing here changes a record in either place. Read access to the source platform's own reports and list views is enough.
Some source platforms only expose a live, moving number rather than a number frozen at a stated moment. Where that is the case, note the time you pulled the source count next to the time the copy's run finished, and treat any gap between those two moments as an expected difference rather than a mismatch. A close match with a stated time gap is a more useful result than an exact match whose timing you cannot state.
Run steps one through six anyway. A copy with no exception reporting of its own does not exempt it from the check; it just means every difference this procedure finds has to be treated as unexplained until you trace it yourself, since there is no vendor-supplied account of the cause.
LedgerCopy trial
A trial conversation establishes four things: the source platform you use, the ledger objects that matter to you, the cadence you need, and the review or continuity workflow the copy has to fit.