Key Takeaways:
-
Contacts are easy, money is hard. Address records have no history. Invoices, payments and credit notes do, and it has to be right.
-
Financial records are immutable, and in Germany that is the law. § 239 (3) HGB forbids changing a bookkeeping entry in a way that hides its original content. A migration that overwrites instead of appending violates the principle the books are built on.
-
The cut-off date is a business decision. How far back do you migrate? "Everything" is rarely the right answer and always the most expensive one.
-
Open items are the critical set. Anything closed can stay in the legacy system if it has to. What is open must come across completely and exactly.
-
The balance check is not negotiable. At the end, balances from source and target have to match to the cent.
In a CRM data migration the effort does not sit with contacts and companies. It sits with the commercial records: invoices, payments, credit notes, open items and contracts. These records carry a history that may be neither altered nor shortened, and their correctness is verifiable against a single number, the balance. Nobody notices a wrong address. Everybody notices a wrong balance.
We supported another CRM project this month, and the same shift happened again: contact data was across in a day, the accounting topics ran for weeks.
Why contacts are easy
A contact has a name, an address, maybe a few assignments. If something is missing, it can be added. If something is wrong, the next person working with it corrects it. The error is cheap and self-healing.
The only real task with contacts is deduplication, and that is solvable. Unpleasant, but a problem with a clear test: is the record a duplicate or not?
Why money is hard
Commercial records have three properties that change everything.
They are immutable. A posted invoice is not edited. It is cancelled and reissued. German commercial law spells this out: under § 239 (3) HGB, an entry may not be changed in a way that makes its original content unrecognizable. The German tax authority's GoBD rules (BMF letter of 28 November 2019, Federal Tax Gazette I p. 1269) apply the same principle to any IT system holding tax-relevant records. If a migration updates records instead of appending to them, the result looks formally correct and is historically wrong.
They are interlinked. A payment belongs to an invoice, a credit note to a payment, a dunning notice to an open item. Migrate the levels separately and you create orphans: payments without invoices, invoices without line items.
They are checkable. That is the real difference. A wrong address may never surface. A wrong balance surfaces immediately, and it surfaces to the person with the least patience for it.
The cut-off question
The most important decision in the project is rarely technical: how far back do you migrate?
Retention law sets the outer frame. In Germany, § 147 AO requires accounting records to stay accessible for up to ten years. Accessible does not mean migrated. It means readable on demand. That distinction is worth money, so we usually propose three tiers:
- Open items: completely, no exceptions. This is the working set.
- Closed transactions from the current and previous fiscal year: completely, because they appear in reports and disputes.
- Everything before that: read-only access in the legacy system or an archive, which satisfies the retention duty without a migration.
The third tier usually saves the largest share of effort and the most error sources. It rarely fails on business grounds. It fails on the wish to switch the legacy system off for good. When that comes up, it is worth pricing the wish openly.
What we check before anything is approved
- Counts per document type, source against target.
- Sums per document type and period. Deviations are explained, not rounded away.
- Open item list at the cut-off date, line for line identical.
- Relationship check: no payment without an invoice, no line item without a header.
- A sample reviewed with accounting, not with IT. Ten transactions, picked by someone who knows which ones are awkward.
Only when those five are clean has a test run passed.
{{feature:data-migration}}
The sequencing mistake
The most common planning error is to start with contacts because they are easy. It feels like progress and creates a false impression of project speed. Four weeks later accounting starts, and the schedule is already spent.
We invert the order: first the full commercial path is exercised on a small slice, from invoice through payment to balance check. Only once that stands do the bulk records follow. It feels slower and it is the shorter route.
At Micromerce we build migration processes so sum and relationship checks run automatically with every run. Nobody repeats them thirty times by hand, so they have to run themselves. If a CRM switch is on your roadmap and the accounting question is the part that worries you, that worry is justified, and solvable.
{{cta:onboarding-check}}
Sources
- § 239 HGB — Führung der Handelsbücher
- § 147 AO — Ordnungsvorschriften für die Aufbewahrung von Unterlagen
- Bundesministerium der Finanzen: Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD), BMF-Schreiben vom 28.11.2019, BStBl. I S. 1269