How separating legacy reports, source-document archives, and new-system opening records preserves the origin and period of every file in an accounting-system change request.
One upload item called System migration documents could hold all of these:
- a final trial balance from the old system;
- a folder of bank statements;
- an opening-balance report from the new system;
- a migration summary;
- a note saying several invoices were transferred manually.
The upload would technically succeed.
The request would still be hard to review because the files do not answer the same question. They come from different places, cover different periods, and carry different limits.
While structuring a document-request checklist for an accounting-system change, I decided not to treat those files as one package. The request needed to preserve where each record came from before anyone tried to decide what it meant.
Three record origins can exist in one transition
A client moving between accounting systems can provide at least three distinct sets of records.
The first set comes from the legacy system. It may include a general ledger export, final trial balance, open invoice report, unpaid bill report, reconciliation reports, or a chart of accounts.
The second set is the source-document archive: bank statements, card statements, invoices, receipts, payroll reports, processor reports, loan records, and lease statements.
The third set describes the new system’s starting point. That may include opening balances, imported open invoices, unpaid bills, an opening account list, a migration summary, mapping notes, known exclusions, and the first reports generated by the new system.
They may all relate to the same client and the same transition date, but they are not interchangeable.
A bank statement is not a legacy-system export. An opening trial balance is not proof that every source document was transferred. A final ledger does not explain which invoices were excluded or entered manually in the new platform.
Once the files are placed in one generic upload item, that origin becomes something a reviewer has to reconstruct from filenames and guesses.
The cutover date needs its own context
The date of the software change is useful, but it cannot carry the entire transition.
I wanted the request setup to record several boundaries explicitly:
- legacy accounting system;
- new accounting system;
- cutover date;
- final legacy period;
- first new-system period.
Those fields help a reviewer ask a much more concrete question.
Instead of asking, “Did the client upload the migration documents?”, the reviewer can ask:
- Does this report belong to the final legacy period?
- Is this the first report from the new system?
- Is there a gap between those two periods?
- Does the source archive cover that gap?
- Were any records excluded or transferred manually?
The cutover date provides orientation. It does not prove that the old system is complete, that the new balances are correct, or that every transaction crossed the boundary.
That distinction matters because a date field looks authoritative even when the surrounding records are incomplete.
A generic item can look complete too early
Suppose the client uploads a final trial balance and nothing else.
If the request contains one item named Accounting system change records, that upload may make the request look substantially complete. A staff member still does not know whether the bank-statement archive arrived, whether open invoices were imported, or whether the new-system report covers the expected first period.
Separate requested items make partial completion visible.
The final trial balance can be Uploaded / Pending review while the migration summary remains Waiting on client. A wrong-period bank statement can move to Needs reupload without reopening the new-system opening report. After review, one item can become Received while the other items remain unresolved.
I used that separation in the accounting system change records checklist: legacy reports, source records, and opening records are collected as related but distinct item groups.
The request still belongs to one client and one system transition. It just does not pretend that every uploaded file has the same review result.
Source documents do not automatically bridge the systems
The source-document archive deserves its own group because it exists independently of both accounting platforms.
A bank statement may support activity recorded in the legacy system, the new system, both systems, or neither one correctly. The document request should preserve the statement and its period without claiming that it has already been mapped to a ledger entry.
The same applies to invoices, receipts, processor reports, payroll records, and loan statements.
Putting those files between the two system exports in a visual sequence can imply that they automatically explain the transition. They do not.
They are evidence that may be reviewed later. Their presence alone does not show that account mappings are correct, that opening balances reconcile, or that the migration included every transaction.
Known exclusions and manually transferred items also need to remain visible. A migration summary that says three invoices were entered manually carries different information from the invoices themselves. Combining the note and the source files into a single upload removes that distinction.
The request should stop before the migration work
A document-collection page can organize the inputs without performing the accounting-system migration.
For this checklist, that boundary means the request can track:
- the client and entity;
- the two systems;
- the cutover periods;
- named record items;
- uploads;
- staff review;
- replacement requests;
- unresolved items.
It should not claim to connect to either system, migrate data, reconcile the platforms, map account codes, repair exports, validate completeness, or calculate opening balances.
It also should not request passwords, API keys, access tokens, MFA codes, or primary login credentials. Those credentials are not extra document context. They change the security and responsibility of the request entirely.
The useful result is narrower: each file keeps a visible origin, period, requested purpose, and review result.
When those details live at the item level, a reviewer can see exactly what arrived and what is still missing.
When they live only inside one large upload box, the files may all be present while the transition itself remains impossible to follow.
Top comments (0)