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.
- objects readable
- 8objects readable
- objects writable
- 3objects writable
- more on demand
- 8more on demand
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.
Two lifetimes, both kept alive here
The write path authenticates with a token valid for two years. The export path is a separate target system whose authentication lasts six months, with no long-lived option at all. Maesn holds both, and your code sees the same account key shape it sees everywhere else.
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 certification 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 certification, the OAuth client, the sandbox and the approval of your integration are the price of entry, and Maesn is a DATEV Interface Partner so that price is paid once, here, for every customer you connect.
Depth you can verify
8 objects readable, 3 writable and 1 updatable in place today, with 8 further combinations available on request. The matrix on this page is the whole truth rather than a selection, including the parts that are thinner than the marketing.
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.
Two Rechnungswesen connections, with two lifetimes
DATEV authenticates through its own login with a SmartCard or SmartLogin, and Rechnungswesen splits what follows in two: the target system you write through and the one you read through are not the same, and neither are their lifetimes. That split is the single most important thing to know before you design the connection.
- Long access token
- Writing, two years, bound to one company
- Export authentication
- Reading, six months, not extendable
Two connections on our side, one account key shape on yours. The difference between them is a lifetime, not an implementation.
- Writing: the long token
- 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: the export system
- A separate target system with its own authentication, valid six months, with no long-lived option because of constraints on DATEV's side. Every call needs a company, which is why the documentation recommends the interactive flow here.
Plan the two lifetimes as one calendar. The write connection runs for two years and will feel like it never expires; the export connection expires twice a year, on a system whose reports somebody is waiting for. A prompt inside your own product costs an afternoon and saves the support ticket.
- 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 both connections are 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.
Two target systems for one product is the sort of detail that quietly becomes a per-system implementation, complete with its own refresh logic and its own failure mode when the shorter of the two runs out. Unified authentication absorbs the difference: both connections are stored, both are addressed through the same account key shape, and what changes between them is a lifetime you plan for rather than code you write.
No Rechnungswesen events, a ledger worth reading
No object here carries a native event. Eight combinations in the matrix are marked on request and every one of them is a webhook, so the event side is a conversation rather than a switch. 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.
- A plan for the six-month re-authentication
- The export connection cannot be extended into a long-lived token. Twice a year your customer confirms it again, so build the prompt for that into your product early rather than discovering it when reporting goes quiet.
Bring your use case and we will tell you which of the two services it needs.
What the Rechnungswesen API exposes
Every object and operation Maesn exposes for DATEV Rechnungswesen. 8 objects are readable and 3 writable today, one of them in both directions, no object sends a native event, and a further 8 combinations are available on request.
Showing 10 of 37 objects · 1 more available on demand
| Object | Read | Create | Update | Delete | Webhook |
|---|---|---|---|---|---|
| Accounts | |||||
| Async task | |||||
| Contacts | |||||
| Files | |||||
| Fiscal years | |||||
| Journal entries | |||||
| Payment terms | |||||
| Tax rates | |||||
| Trial balance | |||||
| Users |
- Supported
- live today
- On demand
- available on request
- Not available
- not offered by DATEV Rechnungswesen
Journal entries are the only round trip
Of the objects Rechnungswesen exposes, exactly one both reads and writes, and it is the booking itself. Everything else goes one way: the trial balance, the payment terms, the accounts and the fiscal years come out, the contacts and the files go in.
Contacts go in and never come back
Contacts can be created and updated in place, and they cannot be read. If your product needs to reconcile what it wrote against what is there, plan to keep that record on your own side, because this system will not return it.
No object deletes by default
No object has delete enabled. Accounting practice expects corrections and cancellations as new documents anyway, so plan them that way rather than around a delete you would have to request.
Coverage is what separates an integration you can build a product on from one that only exists to show a logo, and the shape here is a ledger rather than an inbox: more comes out than goes in. What comes out 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.
The other half of a matrix is what it does not carry. Invoices, bills and credit notes are not objects you write here, and the documentation is explicit about why: those 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.
