Business Central Consultant, Germany

Posting groups: the matrix behind every German entry

Business Central decides which general ledger accounts a transaction hits through posting groups rather than through the user choosing accounts. A sales invoice line combines the customer's business posting group with the item's product posting group, and the combination points to revenue, cost and discount accounts. VAT works the same way, through VAT business and product posting groups. Customers, vendors, inventory and fixed assets have their own groups for balance sheet accounts.

This design is powerful, but it is easy to build badly. Partners sometimes copy a matrix from a previous customer, and the result carries combinations that make no sense for your business. I design the matrix from your scenarios:

• which customer groups need separate revenue accounts, for example domestic, EU, export and intercompany
• which product groups matter for margin reporting, such as goods, services and freight
• which VAT combinations cover the cases your advisor lists
• which accounts your advisor's chart structure expects for each combination

Every combination in the setup must be one we can explain. Empty or unused combinations are removed so users cannot post into them. I then test each combination with a sample document and compare the resulting entries with the expected accounts. The general product context is on my Business Central consultant page.

Dimensions for cost centers, cost units and projects

German controlling usually expects results by cost center and often by cost unit or product line. In Business Central these are dimensions attached to entries. A small number can be global dimensions, available directly on entries and in filters, while others are shortcut or additional dimensions. Choosing which dimension is global matters because changing it later is a significant exercise.

Decisions I make with your controller:

• Which dimensions exist. Typically department or cost center, product line or cost unit, and project or order where relevant.
• Which are global. The ones used most in reporting and filtering.
• Mandatory rules. Expense accounts require a cost center; revenue accounts require a product line; balance sheet accounts usually require none.
• Defaults. Dimensions inherited from customers, vendors, items, employees or fixed assets, so users rarely type them.
• Allocations. How shared costs move between cost centers, using allocation journals or a recurring method.

I also check how dimensions flow into the export your Steuerberater receives, since advisors often want cost center information alongside postings. Before go-live, a month of test transactions should produce a cost center report that the controller recognizes. The wider German context, including data location and the works council, is on my Dynamics 365 consultant Germany page.

VAT statement, SEPA files and bank reconciliation

The advance VAT return in Business Central is produced from a VAT statement: a set of lines that sum VAT entries by posting group combination and type. The German localization supplies a starting statement, but every new VAT posting group combination must be added to the right line or it disappears from the return. I review the statement whenever the posting matrix changes and compare its result for a test period with an independent calculation by your advisor.

Payments run through journals:

• Supplier payments. A payment journal suggests due invoices, and an approved batch is exported as a SEPA transfer file for release in e-banking. Check which file version your bank expects and whether your partner provides an app for it.
• Direct debits. Customer mandates are stored in Business Central and used in collection batches, with returned debits handled through a defined process.
• Bank reconciliation. Statements are imported, by file or bank service, and matched with rules that recognize invoice numbers and customer names.

I write each of these as acceptance tests with your bank's participation, not as assumptions in the proposal. The Zoho Books Germany page covers a lighter alternative for companies whose needs stop at invoicing and payments.

Reading a partner's statement of work for Business Central

The statement of work is where most project risk sits, because it defines what the partner promised and what you assumed. German proposals tend to be detailed, which helps, but detail is not the same as coverage. I compare it against your requirement list and look at specific areas:

• Scope by process. Is each requirement mapped to standard functionality, an app, an extension or explicitly excluded?
• Apps and their licensing. Which third-party or partner apps are included, how they are licensed and who supports them through Microsoft's update cycle.
• Extensions. How many custom extensions, who owns the code, and how they will be maintained across updates.
• Data migration. Which data the partner migrates, which data you must clean and deliver, and how many trial loads are included.
• Testing and acceptance. Who writes test scripts, how many test cycles are planned, and what counts as acceptance.
• Key user effort. How much time your staff must commit, which is often underestimated.
• Support after go-live. Hypercare period, response terms and how change requests are priced.

From that reading you get written questions and proposed contract amendments for the negotiation. Many partners welcome this, because a clearer contract reduces disputes. My vendor proposal review page explains how such a review runs on any platform.

When Business Central is not the right fit in Germany

Business Central suits many German mid-sized companies and subsidiaries. I recommend looking elsewhere when:

• The company is small and service-led. Partner-led implementation and ongoing support may outweigh the benefit; Zoho Books with the advisor keeping the books can be enough.
• Production is complex and the team wants to adapt the system itself. Odoo Accounting in Germany within a full Odoo setup deserves comparison.
• The group runs a larger Microsoft ERP with a global template that the German entity must join.
• Partner fees after go-live are not budgeted, even though updates, apps and changes normally run through a partner.
• An existing system works. If the current ERP is supported and not blocking anything, a change project adds risk without a clear gain.

A wider view of the options is on my ERP consulting for Germany page, and the Germany overview explains how remote projects with German teams run. If you are choosing between partners, my ERP vendor selection service runs that process.