How to integrate DATEV E-Rechnungsplattform: The document travels, the platform routes

It is DATEV’s platform for sending and receiving electronic invoices in a compliant format, and its role inside the DATEV landscape is transport. It is not an accounting system and not a replacement for one: it connects an invoicing workflow to a network, and it connects that network to the applications where the invoice is reviewed and booked.

The formats it carries are the German standards, XRechnung and ZUGFeRD, and the network it carries them over is PEPPOL. What that means for a software vendor is narrower than the product page suggests: the platform is deeply embedded in DATEV, so it is relevant to you when your product creates outgoing invoices for customers who live in DATEV.

Where it fits among the pieces that do have interfaces is worth setting out early. The DATEV overview lists the data services and their two target products, and this platform is the one DATEV component in that picture without a target system of its own.

PEPPOL is a network for exchanging invoices and other business documents in a standardised way, originally an EU initiative for cross-border procurement. The part that matters for an integration is its shape: documents do not travel from sender to recipient directly.

They travel through the four-corner model. The sender hands the document to its own access point, that access point delivers to the recipient’s access point, and the recipient receives it from theirs. Two intermediaries, both certified, and neither of them belongs to the sender or the recipient.

The DATEV E-Rechnungsplattform is the access point for a business that works in DATEV. So the question for your product is not how to speak PEPPOL. It is whether you bring your own access point or use your customer’s.

Both answers are legitimate and they lead to different work. With your own access point or a service provider, you send and receive independently of which accounting product the customer runs. Without one, the platform your customer already has is the route, and your job ends at handing over the document.

Two directions, and they are asymmetric in a way that decides whether your product is involved at all.

Inbound. A supplier sends an invoice over PEPPOL, the platform receives it into its e-invoicing inbox, and it moves on into DATEV Unternehmen Online. There a person approves it and a payment can be initiated, and the structured data reaches DATEV Rechnungswesen for bookkeeping, either in house or at the tax advisor.

Outbound. An invoice is created in an invoicing application, which can be yours. It goes to the platform, the platform sends it over PEPPOL, and in the same step it is made available to Unternehmen Online so the accounting side has it too.

Read those two together and the asymmetry is the point: the inbound path runs from one DATEV component to the next and never leaves the ecosystem. External software has nothing to do in it. The outbound path starts where the invoice is created, which is where a product like yours lives.

DATEV lists the platform’s interface among its data services as the TRAFFIQX Invoice API, which it describes as enabling bidirectional exchange with the DATEV E-Rechnungsplattform and with other providers in the TRAFFIQX network. It runs on the online API traffiqx:invoice and carries its own interface requirements, the same shape of release process as every other DATEV data service.

What the endpoints look like and which formats they take sits behind that separate requirements document, so scope a feature against it with DATEV rather than against this paragraph. Invoices sent from external software are priced per outgoing invoice on DATEV’s side, which belongs in the conversation early.

What does not depend on that answer is an e-invoicing feature, because the invoice itself is a document and the document route into DATEV is documented and open. That route is what the rest of this article describes.

So the honest architecture today has two halves. The transport over PEPPOL is your customer’s platform or your own access point. The accounting side, meaning the document and the structured record arriving where the advisor works, is the existing Unternehmen Online route.

Deliver the invoice as a document, and deliver the data about it as a record. That is the same two-part write every other document takes into DATEV Unternehmen Online, and an electronic invoice is not a special case of it.

One detail decides whether your upload is accepted, and it is a property of your customer’s DATEV rather than of your code. Which file extensions a client may upload depends on that client’s DATEV status, and DATEV exposes that list per client, so the robust implementation reads it at connection time instead of assuming a fixed set.

Through Maesn both halves are one call each against the common data model, and the Unternehmen Online guide has the mechanics: every write is asynchronous, the task id is the only acknowledgement, and the document and the record travel through two different DATEV data services.

Which of the two DATEV products a payload belongs to is its own decision, and the comparison of the two answers it from the object side. For the structured half, the format is decided by the destination rather than by preference, which the guide to the DATEV formats sets out.

Four conditions, and it takes all four rather than one:

• Your product creates outgoing invoices that have to leave in a compliant electronic format.
• You are not responsible for incoming supplier invoices, which is the normal case, because that path stays inside DATEV.
• Your customers work in the DATEV ecosystem, either with in-house bookkeeping or with a tax advisor.
• You do not bring your own PEPPOL connection, so the transport has to be somebody else’s access point.

If the fourth one does not hold, this platform is not on your critical path at all: you send over your own access point and use the DATEV route only for the accounting copy. If all four hold, your work today is the document handover, and the transport is a configuration on your customer’s side.

Two things Maesn absorbs, and both are about the accounting side rather than the network:

• The document and the record. One data model, one account key, and the translation into the DATEV data services and their formats happens here.
• Access to DATEV without the partner process first. You build on the Maesn client, so nothing has to be applied for, paid or waited on before your first call. Becoming an official DATEV Interface Partner in your own name later is a process we run with you, and the DATEV fees for it are yours.

Three things do not move:

• The PEPPOL transport. An access point is a contract and a service, not a field in an interface. Yours or your customer’s, and that choice is a product decision.
• The invoice content and its validity. XRechnung and ZUGFeRD have rules, and the invoice your product generates has to satisfy them before anything transports it.
• What you promise about timing. No interface exists for the platform today, so a roadmap that depends on one is a risk to carry openly rather than to plan around.