A Danish business moving to a digital bookkeeping system should buy a reconciled migration, not simply a successful import. Finance must be able to explain each opening balance, locate the supporting records and understand which system owns new transactions after cutover. Those outcomes belong in the software scope before data is moved.
The Danish Business Authority’s Bookkeeping Act guidance describes the 2026 extension of digital bookkeeping requirements to qualifying businesses outside the annual-reporting obligation, including the test of net turnover above DKK 300,000 in two consecutive income years. Timing and scope depend on the business’s circumstances. Have the responsible adviser establish applicability; the project below focuses on implementing an agreed move reliably.
Decide what is moving and what remains available
Consider a fictional Danish service business whose invoices are produced in one application, bank reconciliation happens in another, and supporting documents sit in shared folders. The new bookkeeping package can import accounts and balances, but that alone does not recreate the links finance uses to explain a transaction.
Create an inventory of records, attachments, references and integrations. For each category, decide whether it will be migrated, retained in an accessible archive or replaced by a documented opening position. Have finance approve that decision before engineers transform the data.
Avoid treating a historical archive as a miscellaneous folder. Specify who may access it, how records can be found and how the business will keep it available for the required period established by its advisers.
Check the selected product and the surrounding system
The authority publishes a register of digital bookkeeping systems. Verify the exact product and configuration you intend to use, and identify any separate responsibility associated with custom components or a non-registered arrangement.
A product selection does not settle the behaviour of an external invoice application, custom approval tool or warehouse connector. Draw the full operating system around the ledger. Mark which component creates each record and which component is allowed to change it.
This is where custom engineering may be useful: preserving references between systems, translating approved business events and making failed transfers visible. Building a replacement accounting engine should not be the default response to a missing integration.
Write reconciliation rules that finance can reproduce
Before the first test import, agree how the team will compare source and destination. A proposed reconciliation pack can include:
- ▸Account-level opening balances for the agreed cutover date.
- ▸Unpaid customer and supplier items with their document references.
- ▸Totals by currency where the business uses multiple currencies.
- ▸Counts of records transferred, excluded and awaiting correction.
- ▸A sample of attachments traced from destination back to source.
- ▸An exception list with reasons and named finance owners.
Use the accounting treatment approved by the business. Engineering should implement and report the mapping, not invent how a financial difference ought to be classified. Keep the calculation method with the results so a second reviewer can reproduce the comparison.
Preserve identity when descriptions change
Migrating systems often changes display names, account labels or document locations. Maintain a durable relationship between the original identifier and the destination identifier. A human-readable description is useful, but it should not be the only way to trace a migrated record.
Test a customer whose name changed, a supplier with several similar accounts and a document reference reused in a different context. The mapping should expose ambiguity for review. Guessing a match can create a problem that is difficult to detect in an aggregate total.
For attachments, verify the actual file and its relationship to the record. A link that opens successfully may still point to the wrong document. Include content checks on an approved sample and investigate any pattern of mismatch before expanding the import.
Rehearse the period around cutover
Choose a clear operational cutover boundary. Establish when each source stops creating new records and when the destination becomes authoritative. Explain how the team handles late-arriving documents, corrections and work already in progress.
Run a rehearsal with a representative copy or approved test dataset. Measure the actual preparation, import and reconciliation steps, including the time needed for human review. A fast import followed by days of unresolved discrepancies is not a successful cutover plan.
Define the conditions for pausing or reversing the migration before the live event. The rollback decision should account for transactions already created in the destination. Finance and operations need a shared rule that prevents both systems from independently becoming the source of truth.
Test every integration after the balances agree
A reconciled opening position can still be undermined by the first day’s incoming events. Test invoice creation, credit handling, bank-related imports and the specific business workflows in scope. Replay a previously processed test event and interrupt a transfer before confirmation.
The receiving system should either identify the existing business record or route uncertainty for review according to the agreed design. Support should be able to distinguish a rejected mapping from a temporary connection failure. Make that distinction visible without exposing unnecessary financial detail to every technical user.
Assign ownership for provider changes. An accounting product update or altered source export can affect a custom connector months later. Include monitoring, change review and a small regression dataset in the handover.
Buy evidence the business can keep
The final delivery should contain approved mappings, reconciliation results, unresolved exceptions, archive instructions and a cutover record. Ask a finance employee who did not prepare the migration to trace a sample opening item through that evidence.
TuniCyberLabs can help implement migration tools and bookkeeping integrations through custom software development. Describe your Danish migration, including current applications, target product and the records that must remain traceable. Use our quote-comparison worksheet to compare reconciliation, rehearsal and support assumptions across proposals.