DATEV Rechnungswesen API Integration
DATEV Rechnungswesen is where a German booking is finally recorded, by a tax advisor or by a company doing its own bookkeeping. It is not one of DATEV's online applications: it runs on a provider's server or the customer's own. Maesn reaches it through the same REST API and the same data model as every other supported system.
The Rechnungswesen ledger, reachable both ways
Rechnungswesen is the end of the chain, and reaching the end of a chain that runs partly on someone else's server takes three things. Here they are, and here is the part Maesn takes off you.
One direct route, one through the portal
Because it is an on-prem application rather than an online one, exactly one service transfers data into it directly. Everything else travels through Unternehmen Online, where the tax advisor reviews it first. Maesn covers both routes on one interface, so which one a payload takes is a parameter rather than a second project.
One login, two years, reading included
Writing and reading run through the same connection, authenticated once with a token valid for two years. Maesn issues the client credentials with the export service already in them, so the ledger answers on the connection your customer has already approved rather than on a second one.
What you post, you can query
Journal entries go in and come back out. The trial balance, the payment terms and the fiscal years only come out, and each of those three is readable on exactly one other system in this catalogue, which is why a reporting or reconciliation product ends up here rather than upstream.
What reaches your code is a REST call and an account key. Teams go live in days, and the system after this one is a configuration step rather than a second project.
The route that is not direct runs through DATEV Unternehmen Online, where your customer’s tax advisor reviews a document before it is submitted here. Most products end up using both, which is why they share one partner status and one connection story. The DATEV overview puts the two systems and the four data services side by side, so this page can stay on the one where the booking lands.
A short call is usually enough to tell whether Maesn fits your use case.
Tipalti posts into Rechnungswesen, in line with GoBD
Tipalti automates accounts payable across Europe, and their case study names this system: bookings and documents go directly into DATEV Rechnungswesen, in line with local accounting standards and GoBD requirements.
“With Maesn, we accelerated our European expansion by making complex ERP integrations seamless across Benelux and DACH. As an AP platform, reliable access to key local ERP systems is critical and Maesn gives us exactly that.”
Three reasons to reach the DATEV Rechnungswesen API through Maesn
A booking that lands in the wrong format is not a bug your customer forgives, and DATEV has more than one format. The work worth outsourcing is the part between your debit and credit lines and what Rechnungswesen accepts.
The DATEV half stays here
The interface partner status, the OAuth client, the sandbox and the approval of your integration are the price of entry, and on the Maesn client you inherit ours, so you start without paying or waiting for any of it. Moving to your own client later is a process we run with you and whose DATEV fees you carry.
The objects a reconciliation needs, out of the ledger
Accounts, journal entries, a trial balance, fiscal years and tax rates come back on the same connection your bookings go in through, in the shape every other supported system returns them in. Tell us which objects your use case works with and we confirm them.
The next system costs nothing
Once this runs, every other supported accounting and ERP system answers on the same interface. Your second integration is a configuration step, and the portal in front of this one is already part of it.
One Rechnungswesen connection, reading and writing
DATEV authenticates through its own login with a SmartCard or SmartLogin, and what your customer approves once covers both directions. Posting a booking and querying the ledger back run on the same connection and the same long token, so the connection your product builds is one connection.
- Long access token
- Reading and writing, two years, bound to one company
- SmartCard or SmartLogin
- DATEV's own login, on DATEV's screen
One connection on our side, one account key shape on yours. Reading and writing are the same authentication, not two.
- One long token, two years
- Valid for two years and bound to the company it was issued for. Your customer picks that company during the flow, and the ID is stored on the connection so nothing downstream carries it.
- Reading on the same approval
- Querying journal entries, the trial balance, payment terms and fiscal years runs through the connection your customer already approved. Maesn issues the client credentials with the export service in them, so nothing on your side switches between a write path and a read path.
One expiry to plan for, two years out. It is far enough away to feel like it never happens, which is exactly why the renewal prompt belongs in your product while you are building the connection rather than in the quarter it runs out.
- 1
Your customer signs in to DATEV
With their SmartCard or SmartLogin, on DATEV's own screen. Nothing about the access medium reaches your product, and nothing about it is specific to Maesn.
- 2
They choose the company
A DATEV login can reach more than one company, and the connection is bound to the one that gets picked. Two companies means two connections, which is worth modelling before your first multi-entity customer arrives.
- 3
You work with one account key
Maesn stores the connection and returns an account key. From there every request carries your API key plus that account key, the same two headers you already send for every other system in the catalogue.
Authentication is where a single system quietly becomes a per-system implementation, with its own refresh logic and its own failure mode on a schedule nobody put in the calendar. Here there is one consent, one token and one expiry: unified authentication stores the one connection your customer approved, and the same account key shape reaches the ledger and the booking endpoint alike.
No Rechnungswesen events, a ledger worth reading
Events are enabled per object on this system, and on a ledger that matters less than it sounds. What runs today is a scheduled read, and on this system that is worth having.
Nothing. No object carries a native event, so a booking your customer's tax advisor posts stays invisible to your product until something goes and reads it. The eight on-demand cells are all webhooks, which is where that conversation starts.
A scheduled read against a ledger that actually answers. Journal entries, the trial balance and the accounts come back through the export system, filtered and paged the same way as every other system you have already integrated.
A pull is the right instrument here rather than a consolation prize: bookings are corrected and reposted, and a read that runs on your schedule sees the corrected state instead of a stream of intermediate ones. The cost is the interval, and the interval is yours to choose.
On the sister system a scheduled read has little to look at, because a delivery portal holds no state you want. Here it has a great deal: this is the one place in the DATEV bracket where a product can ask what was booked and what the trial balance says. One way to filter and page is what makes that read the same shape as every other read you run, so a reporting feature written against one system keeps working against the next.
What Rechnungswesen needs before the first booking
Your customer may be hosting this destination themselves, so what has to exist before the first call is partly infrastructure rather than only settings.
- An instance, hosted by a provider or by your customer
- Rechnungswesen is not a cloud product you sign up for. Your customer runs it, or someone runs it for them, and the subscriptions your use case depends on have to be on that instance.
- The service for the direction you need
- Writing bookings and reading them back are two different DATEV services, ordered separately. Maesn documents the configuration of each one, and which of the two you need follows from your use case rather than from the setup.
- An access medium, and rights that match it
- A SmartCard or SmartLogin, plus the access rights configured in DATEV Rechteverwaltung Online. That tool belongs to the tax advisor, so this step is a conversation with your customer rather than a task in your backlog.
Bring your use case and we will tell you which of the two services it needs.
Which DATEV system holds the data you need
Rechnungswesen is the ledger of the three DATEV target systems, and what comes out of it is what a reconciliation needs.
What you read arrives in the shared common data model, so a journal entry from Rechnungswesen has the same fields as a journal entry from a cloud system with a REST API of its own, and the reconciliation you write once survives the next integration.
Documents take a different route on purpose, and the documentation is explicit about why: they travel through the portal so the tax advisor can review them first. DATEV also runs an e-invoicing platform, a target system of its own with its own integration guide. Deciding early which of the three holds the data your use case is about saves more time than any amount of endpoint reading.
Tell us which objects your use case needs and we will confirm what is possible.
