System Integration Consultant, Germany

The handoff to the Steuerberater and DATEV

Many German companies keep operational bookkeeping in their ERP while the Steuerberater prepares the advance VAT return, payroll and annual accounts in DATEV. The interface between the two is therefore one of the most important in the whole landscape, and also one of the most frequently improvised. Typical symptoms are postings that arrive with the wrong tax key, customer and supplier accounts that do not match the advisor's numbering, missing document links and corrections every month.

I specify this interface with the advisor rather than around them:

• Which data moves: postings only, or also account master data, open items and document images.
• How accounts, cost centers and tax keys map between the ERP's chart and the advisor's.
• How corrections are handled once a period has been exported, so changes do not quietly reappear.
• Which export format and transfer route the advisor's setup accepts, and how often data is sent.
• Who checks the export before it leaves, and who answers the advisor's questions.

A trial export from test data goes to the advisor before go-live, and their feedback is part of acceptance. Whether a particular ERP's standard export suffices or needs an add-on is checked per product. The bookkeeping and procedure questions around this interface belong with your advisor; my job is a reliable, documented flow. Context on German ERP projects is on my ERP consultant page for Germany.

XRechnung, ZUGFeRD and invoices to public customers

Structured e-invoices are becoming the norm between German businesses, and public sector buyers already ask for them. The legal scope and timetable for your company sit with your tax advisor. The integration question is practical: how structured invoices arrive, how they are checked and booked, and how your own invoices leave in the right form.

On the receiving side I design:

• The reception channel, such as a dedicated mailbox, a portal or an e-invoicing service, and how files reach the ERP.
• Validation of the structured data and a readable view for the people approving the invoice.
• Matching against purchase orders and goods receipts, with clear rules for differences.
• Storage of the original file alongside the posting, in line with the archiving expectations your advisor confirms.

On the sending side, the ERP must fill every mandatory field from master data, including identifiers public customers require, such as a routing reference supplied by the buyer. Invoices to federal or state bodies may go through their own submission portals or through Peppol; I test the route each customer group needs. Many failures here are data failures, so customer and supplier master data cleanup belongs to the same plan. If the ERP itself is being replaced, these cases join the test catalog described on my ERP implementation consultant page for Germany.

Banks, EBICS and the payment run

German companies commonly exchange payment and statement files with their banks over EBICS, either directly from the ERP, through a separate banking program or through a payment service. Others upload files in online banking. Each route has consequences for security, signatures and who can release payments, so I design the flow with your finance lead and the bank's technical contact.

The specification covers SEPA credit transfers for supplier runs, SEPA direct debits with mandate references and sequence types maintained correctly, and CAMT statements imported for reconciliation. For each I decide how the ERP handles rejections and returns, how bank charges and interest post automatically, and which remittance information allows receipts to clear the right open items. Where signatures are applied in the banking program rather than the ERP, the hand-off between them is documented so nobody can release a file that was changed after approval.

Online payment providers and marketplaces settle net of commissions and refunds. Each settlement is broken down into customer receipts, fees and refunds so that the bank line and open items agree without a spreadsheet in between. Testing uses real files from each bank, a deliberately rejected payment and a returned direct debit, and the finance team signs off the results before cutover.

EDI with industrial customers, shops and logistics partners

German suppliers to vehicle makers, machine builders or large retailers often receive orders and delivery schedules by EDI and must answer with dispatch advice and invoices in the customer's format. The EDI provider or converter handles the format and transmission; the ERP must provide and accept the right data at the right moment. I specify how call-offs and schedule changes update planned orders, how labels and dispatch data are produced and how rejected messages reach someone who can act.

Online channels bring their own requirements. Orders arrive from a webshop or marketplace, stock and prices are published back, shipments and returns are confirmed. The first decision is master data: the ERP normally owns items, stock and cost, while product content may live in the shop or a product information tool. Item codes are matched once and kept in a mapping, not adjusted by hand in each channel.

Where a logistics partner holds stock, its messages for receipts, picks, shipments and inventory are specified from its interface documentation, and a daily comparison of stock figures is assigned to a named person. Scenario tests run across the chain: a changed call-off, a split delivery, a return, a web order refunded after shipment. Customer-facing CRM data rules are on my CRM consultant page for Germany.

Method, payroll journals and ownership after go-live

For each interface I compare the possible methods with written reasons. A standard interface delivered with the ERP is the first choice if it covers your cases. Middleware, whether a commercial integration platform or tools such as Make, n8n or Zoho Flow, suits landscapes where many systems share the same records. Custom development via APIs suits high volumes or special logic, with maintenance responsibility named up front. File exchange remains normal for banks, advisors and payroll.

Payroll is a good example. In many German companies it runs in DATEV at the Steuerberater or with a payroll provider, and the ERP receives a journal each month. I map wage types to accounts and cost centers with the advisor, define the control total against the payroll summary and agree who reviews the posting. Employee data stays in payroll; only summarized figures reach the ERP.

After go-live every interface has a named owner, alerts that reach that person, retry limits and a daily check of counts and totals, plus a runbook the team can use without the original developer. Interface logs may also be of interest to the works council where they record user activity, which your HR team assesses. The global approach is described under system integration and ERP integration; the Germany overview lists related work. All of it is delivered remotely; visits can be arranged.