DATEV Partnership Guide: How to get listed in the DATEV Marktplatz

DATEV runs three categories for software vendors, and only two of them are partnerships. The one almost every integration needs is the third, which is not a partnership at all. Getting the words right matters here, because they decide what you may put on your own website later.

A DATEV Schnittstellen Anbieter, an interface provider, is a vendor that has implemented a DATEV data service and passed its technical release. There is no application and no partner contract. DATEV writes it without room for interpretation: “DATEV Schnittstellen Anbieter sind keine DATEV-Marktplatz Partner.”

What the connection itself involves, from the data services to the objects behind them, is on the DATEV API page.

The two partnerships sit above that. A Marktplatz Schnittstellen Partner applies and is chosen. A Premium Partner does not even apply: DATEV initiates that relationship, and the FAQ states that an active application is not possible.

This is the part that turns the approval from a badge into a dependency. Your customer does not authenticate to your product, they authenticate to a named app registered in the DATEV developer portal, and until that app is released for production it cannot ask them for anything.

DATEV asks you to choose the name carefully, and gives the reason in the same breath: “Geben Sie der App einen Namen. Der Name sollte dem Nutzer bekannt sein, da er auf der Consent Page erscheint.” The registration also carries an Anbietername, the company name behind the app. So the question of whose brand a tax adviser reads before clicking accept is settled long before the dialog opens.

The second half of the dependency is in the interface requirements, under architecture. Production credentials are not self service: “Einen produktiven API-Client kann sich aber nicht jeder beliebige API-User generieren. Hier wären immer gemeinsame Freigabetermine mit DATEV erforderlich.”

Put the two together and the sequence is fixed. Approval comes before the first customer, not after the first ten. Every plan that plots pilot customers before a DATEV release date has the order wrong, and the fix is scheduling rather than engineering.

Every new cloud integration goes through a joint release process with DATEV, and it takes at least two meetings. The first releases your sandbox work, the second releases you into production. Between them runs a deadline that is easy to miss on a roadmap.

After a successful sandbox meeting, DATEV writes that the vendor “erhält … für die nächsten 3 Monate den Zugang auf die Produktionsumgebung”. Production access is therefore temporary at first. Only the production release removes the limit, and from then on the integration may run at every customer.

The meeting itself is a video call in which you share your screen. A DATEV consultant moderates, asks questions and sets challenges to demonstrate that the requirements are met, and “parallel prüft der Berater die im DATEV API-Gateway erzeugten Log-Sätze auf Konformität”. In the production meeting the exchange with the DATEV applications is checked as well.

One instruction is worth reading twice, because it contradicts the instinct to make a demo realistic. Involving first customers is recommended, and yet: “Im Rahmen der technischen Prüfung dürfen keine Echtbestände oder Echtdaten verwendet werden!” Prepared test data, in a real system, is the combination being asked for.

The requirements are graded as MUST, SHOULD and DONT, and the MUST items are the ones that decide the meeting. Most of them are not about the calls you make. They are about what your product shows the user and what it keeps afterwards.

The connection screen is specified in unusual detail. DATEV expects a clear separation between establishing the connection and exchanging data, and then names the elements it wants to see.

A button that starts the process, a visible connection state, a button that disconnects and revokes, the calculated expiry date of the refresh token, the full name of the person who issued it, and a link to DATEV’s own app for connected applications. Six items, all of them in your interface rather than in your integration layer.

The token model is worth planning for at the same time. An access token lasts 15 minutes and a refresh token 11 hours, and refresh tokens are single use, so replaying one invalidates the whole session. A two year token exists behind the offline_access scope, but it is bound to a single client and only works where that client id is part of the path.

Here is where DATEV parts company with the other accounting platforms. The listing is not a tier you buy into to find customers. It is something you apply for once a data service you implemented is already used by at least 25 of them.

The application asks for three reference customers, and DATEV speaks to them itself rather than reading a case study. Then comes a first conversation, a separate appointment for a detailed product presentation, and a decision. For payroll integrations the same threshold applies specifically to the DATEV Lohnaustauschdatenservice.

The sentence that settles the expectation is DATEV’s own: “Die Erfüllung der oben genannten Bewerbungsvoraussetzungen führt nicht automatisch zur Zusage einer Partnerschaft.” What is weighed is whether the solution complements DATEV software, judged case by case.

Two details in that order are easy to skip past. The technical review comes after the partnership decision rather than before it, and it does not end there: DATEV states that the interfaces of these partners are reviewed regularly. The listing is a relationship under maintenance, not a milestone.

Set against the other two programmes, the inversion is complete. Xero sells a tier and opens the App Store at Plus, Intuit marks its marketplace listing as optional at every paid tier. In both cases the listing is a lever you can pull on the day you decide to. Here it is a consequence of traction you already have, and no amount of budget moves it forward.

There is no rate card to compare, and that is genuinely unusual in this field. DATEV describes the gateway itself as “für API-Consumer (Softwarehersteller) derzeit kostenfrei”, free of charge for software vendors at present. No tiers, no per call price, no published fee for the release process.

The costs sit at the edges instead, and all three are worth pricing into a plan. Interface consulting is chargeable without a partnership. Exceeding the ten percent error rate after the production release triggers a chargeable re-inspection. And free DATEV test software is listed as a benefit of the Marktplatz partnership.

One more requirement carries a cost that never appears as an invoice. Information security certification became mandatory for Premium Partners on 30 June 2026, with an extension to 31 December 2026 for anyone who had already started the process. For Schnittstellen Partner it is recommended rather than required.

Maesn is an official DATEV Interface Partner, in German an offizieller DATEV Schnittstellenanbieter. DATEV lists us in its interface provider directory as maesn von maesn GmbH, with three data services named there: Belegbilderservice Rechnungswesen, Buchungsdatenservice and Rechnungsdatenservice 1.0. That is checkable in one click, which is the only kind of status claim worth making.

What that removes from your side of the line:

• The formats stop at our door. DATEV publishes 13 data services, and three of them carry a second specification for their file format alone, CSV, XML and ASCII. You send and read JSON on the same endpoints you use for every other system.
• Sandboxes exist without a DATEV trial. Neither DATEV product offers a free trial account, so we run sandboxes for both DATEV Unternehmen Online and DATEV Rechnungswesen, and building starts before any DATEV process finishes.
• The bursty writes are absorbed. Our asynchronous endpoints for booking proposals, files and expenses handle rate limits rather than passing a 429 back, and they were built for DATEV first. Against a ten percent error budget that is the difference between a metric and a re-inspection.

What stays with you, and none of it is a formality:

• Your own status, under your own name. The consent page names the app that was registered, so if your brand belongs in that dialog you need the status yourself. We take our customers through it and stay in the background: you become an official DATEV Schnittstellenanbieter, and the interface carries your name rather than ours.
• Your customer’s DATEV configuration. Five prerequisites sit in their environment, from an active fiscal year to the Belege Online app in the right mode and an access medium with the right rights. No integration reaches around a missing one.
• The Marktplatz decision. Once the further conditions above are met we support that step too, but the 25 customers are yours to win and the reference calls are yours to pass. How the other platforms handle the same step is collected in the accounting integration partnerships guide.

One limit belongs in the open rather than in a footnote. The long lived token that keeps a connection alive for two years is bound to a single client, and it only works with APIs that carry that client id in the URL path. A partner serving one customer with several DATEV clients therefore holds one connection per client rather than one per customer.

That is worth modelling before your first multi entity customer arrives, because it shows up in your data model rather than in a call, and DATEV asks you to explain the mapping between your entities and theirs during the approval meetings.