Daily Copy
How a LedgerCopy run works.
A run has three parts: a read-only authorisation to a supported source, a dated pass that writes supported records into independent storage, and a run report that states what the pass copied.
Part one
Authorising a source
A run cannot start without an authorisation to a supported QuickBooks Online or Xero organisation. The authorisation is granted at the source platform by someone who can already administer it there.
What a run reads
- The platform's own APIA run reads through the interface the source platform publishes. It does not touch the source database and does not use anyone's login session.
- The object groups in scopeA run requests the supported object groups agreed for your organisation during scoping. Anything outside that scope is not requested and is not copied.
- Read requests onlyWhere a platform's authorisation is not granular, the boundary still holds in what LedgerCopy asks for: a run issues read requests and no others.
What a run never does
- It does not write backLedgerCopy creates, edits and deletes nothing in QuickBooks Online or Xero. The copy is a destination, never a source of changes.
- It does not change accessA run does not alter users, roles or permissions at the source. It reads what the authorisation already allows.
- It cannot keep itself connectedAuthorisation is revoked at the source platform, not by asking LedgerCopy. Revoking it stops every future run.
Part two
The dated run
A run is a scheduled pass. It reads supported records from the authorised source and writes them into storage LedgerCopy operates independently of that source.
Every run carries a run date, and the records it writes are filed under that date. A later run does not overwrite an earlier one, so the copy is a series of dated runs rather than a single moving snapshot.
Cadence is agreed during scoping. A daily cadence is the shape of the Daily Copy direction, but the cadence for your organisation is set with you before the first run rather than asserted here.
When a run is closed
A run is closed only once its result has been recorded for every supported object group in scope. The result is one of three values: the group was copied, the group was copied with an exception, or the group did not finish.
A pass that stops before every group has a recorded result is not closed as complete. It is reported as incomplete, and an incomplete run is never presented as the current copy.
Part three
What a run reports
Every dated run records the same six fields. Because the fields do not change between runs, two runs can be read against each other line by line.
| Field | What it records, and how to read it |
|---|---|
| Source | The platform the run read from, and the authorised organisation inside it. Reading itWhere more than one organisation is connected, this field is what tells you which one the report in front of you covers. |
| Run date and completion time | The date the run belongs to, and the time the pass finished, recorded in UTC. Reading itCompletion time is the useful number, not start time. UTC is used so that a run read from two countries is read the same way. |
| Supported object groups covered | The object groups that were in scope for this organisation on this run. Reading itThis is the coverage line. A group that is not listed was not copied, whether or not it exists in the source. |
| Records written per group | The number of records written into the copy, counted separately for each object group. Reading itCounts are most informative against the previous run. A count that moves sharply in either direction is worth a question, and both runs stay on record to compare. |
| Exceptions raised, by group | The number of exceptions this run raised, attached to the object group that raised them. Reading itAn exception count names the group and the number, not the cause. Causes are source-dependent, and the report does not guess at them. |
| Run outcome | One of three values: complete, complete with exceptions, or incomplete. Reading itComplete and complete with exceptions both describe a finished pass; the second says the finished pass has something attached to it. Incomplete describes a pass that stopped. |
An example run report
Outcome: complete with exceptions
| Object group | Records | Result |
|---|---|---|
| Accounts | 94 | Copied |
| Transactions | 17,906 | Copied |
| Contacts | 642 | Copied |
| Attachments | 1,284 / 1,301 | Review |
Coverage note 17 attachments are recorded as an exception on this run. A completed run is a record of what was copied, not a tested export.
The same six fields are what a manual check has to reconstruct by hand. If you are checking a copy today, whoever holds it, the procedure is written out separately.
Scoping a trial starts from this specification: which source, which object groups, and which cadence your run report should carry.
Request a trialDefinition
Exceptions
An exception is a record or object group that a run could not copy completely, or copied with a difference the source reported. It is raised against a group, and it carries a count.
What raises one
- An object the source did not returnThe run requested a record that was in scope and received nothing for it.
- A permission the authorisation does not coverThe connected authorisation is not scoped to an object the run asked for, so the request is refused at the source.
- A source API limit reached mid-runThe platform stopped serving requests before the group finished, so the group is recorded short.
- A record the source reported with a differenceThe source reported a count or a file that does not match what the run wrote, such as attachments held against a record.
What happens next
Causes are source-dependent. LedgerCopy names the object group and the count; it does not diagnose the source platform, and the report records what the source returned rather than an interpretation of it.
- The exception stays attached to its runIt belongs to the dated run that raised it. Reports are not rewritten after the fact.
- The following run retries the groupThe next scheduled pass requests the same group again and records its own result.
- Unresolved exceptions stay visible across runsA later success does not clear an earlier record. You can see how long a group has been raising exceptions, not only whether it raised one today.
Failure behaviour
When a run does not complete
Runs stop for ordinary reasons. What matters is that the report says so, and that a stopped run is not dressed up as a finished one.
- Partial run
The groups that finished are recorded with their counts. The groups that did not are recorded as unfinished, with an exception against each, and the outcome is incomplete.
OperatorThe outstanding groups are retried on the next scheduled pass. The incomplete run stays in the history beside that retry, so the two can be read together.
- Source API error
The report shows the group that was in progress, the records written before the error, and an exception against that group.
OperatorAn error that repeats across runs is treated as a scope or cadence question rather than a one-off, and is raised with you before the run configuration changes.
- Revoked or expired authorisation
The run is recorded as incomplete with no records written, and the source is recorded as unauthorised for that run.
OperatorA new authorisation has to be granted at the source platform. LedgerCopy cannot restore access from its side, by design.
- Source unavailable
The run is recorded as incomplete, with the time the pass stopped. Nothing is written from a source that did not respond.
OperatorThe run is retried on the next scheduled pass. The last complete run stays the most recent dated copy on record.
An incomplete run is reported as incomplete and stays in the run history in that state. It is never counted as the current copy, and it does not replace the last run that finished.
Boundary
What the copy is not
The copy is useful because its scope is stated. The same honesty applies to what it does not do.
- A completed run is not a tested exportIt is a record of what was copied. It is not evidence that the data has been exported and read back into a working system.
- The copy is not a restoreLedgerCopy does not write to QuickBooks Online or Xero. Returning data to a source platform is that platform's process, not a LedgerCopy function.
- The copy does not replace the sourceThe ledger of record stays in QuickBooks Online or Xero. The copy exists so that its scope can be inspected outside the platform that produced it.
- Coverage is stated, not assumedCoverage is source-dependent. The supported object groups for your organisation are confirmed in writing before the first run, and anything outside them is not copied.
Export and recovery routes are described only where they have been tested, and they are named per platform on the coverage page. Routes that have not been tested are not described.
LedgerCopy trial
Request a trial and scope the copy.
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.
What to have ready
- Which organisation or company file the copy would cover.
- Who can authorise a read-only connection at the source platform.
- Which object groups you check at close.