ERP system development
in Munich

For a company in Germany, two sets of rules shape an ERP from the first sprint. One covers how electronic books are kept. The other covers how invoices travel between businesses. Both change the data model, so they belong in the specification rather than in a later patch.

The first set is known as GoBD, the principles issued by the finance ministry for keeping and storing books and documents in electronic form. They prescribe no product. They describe properties any system holding tax relevant data must have.

Immutability comes first. Once a booking is recorded, it may not be changed in a way that hides the original entry. A correction becomes a new, visible entry that points to the old one. In practice this means no silent edits on posted documents, no delete button on journal lines, and a change log that records who changed what and when.

Traceability follows from it. An auditor must be able to follow a single business event from the source document through each booking to the financial statements, and back again. Every invoice, credit note and payment therefore needs stable references that survive exports, archive moves and system upgrades.

The third requirement is procedural documentation. The company has to describe how its system takes in, processes and archives data, and which internal controls run. With a custom ERP, much of this text can only come from the people who built it. Budget for it as a deliverable.

Retention closes the loop. Tax relevant records must be kept for statutory periods that run for many years and differ by document type. Data born digital must stay machine evaluable for the whole period, so a printout is not enough. During an audit the tax authority may access the data, which calls for a clean structured export.

The second set of rules concerns invoices between businesses. Germany has made structured electronic invoices the norm for domestic B2B trade. Since the start of 2025, every business must be able to receive them. Transition periods apply to sending, and they end in stages over the following years depending on the size of the company. A plain PDF sent by email no longer counts as an electronic invoice under these rules.

The accepted formats follow the European standard for e-invoices. XRechnung is a purely structured XML format. ZUGFeRD is a hybrid: a PDF that a person can read with an embedded XML file that a machine can process. An ERP has to create both, validate incoming files, map their fields onto its own vendor and item records, and store the original XML as the document of record. The readable view is a convenience; the data is the invoice.

One more point touches people rather than tax. An ERP that logs who did what can, in principle, be used to monitor employee behaviour or performance. Where a company has a works council, introducing such a system is subject to co-determination. Plan the role and log design early and share it with the works council, so the rollout is not held up at the last moment.

Every ERP ends up with a permission model, whether anyone designs it or not. If nobody does, it grows by request. A user needs to post one invoice, so someone grants a broad finance role. A manager is on holiday, so a colleague gets his rights and keeps them. A year later, most people can do most things.

Designing it properly starts with tasks, not with job titles. List what people actually do in the system: create a supplier, change bank details, approve a purchase order, post a goods receipt, release a payment run, edit a price list. Each task becomes a permission. Roles are then bundles of permissions that match real work, and a person can hold more than one role.

Segregation of duties is the rule that certain tasks must never sit with one person. The classic pairs are easy to name. Whoever creates a supplier should not also be able to pay it. Whoever records stock movements should not be able to adjust the stock valuation. Whoever sets up a customer credit limit should not also release blocked orders for that customer. Each pair closes a path to fraud or to unnoticed error.

The pairs belong in a conflict matrix, kept as data inside the ERP rather than in a spreadsheet on a shared drive. When an administrator assigns a role, the system checks the matrix and warns or refuses. When the matrix changes, a report shows which existing users now hold a forbidden combination. That report is worth running before every audit.

Small companies face a real tension here. With four people in finance, a perfect split is impossible. The honest answer is a compensating control. One person may hold both rights, but every use of the second right creates an entry that another person reviews weekly. The ERP keeps that review cheap.

Permissions also have a data dimension. A buyer in one plant may create orders only for that plant. A sales rep sees the margins of his own customers and nobody else. Restrictions like these often make custom ERP work expensive. Decide early which dimensions matter, since adding one later touches every report.

Then there is emergency access. Sometimes an administrator must fix a blocked posting at night. Give that access through a separate, time limited account whose every action is logged and reviewed the next day. Never quietly widen a normal account.

Finally, roles decay. People change jobs, projects end, contractors leave. Schedule a review in which each department head confirms the access of their team, and let the ERP produce the list for them. Removing a right should be as quick as granting it. If it is not, nobody will bother.