DATEV Unternehmen Online API Integration
DATEV Unternehmen Online is the platform a German business shares its receipts and accounting data through, and the place its tax advisor picks them up. Connect it through Maesn and your product writes into that environment with the same REST API and the same data model as every other supported system.
- objects readable
- 5objects readable
- objects writable
- 4objects writable
- more on demand
- 2more on demand
Documents land in Unternehmen Online, where the advisor works
Most systems on this site are a database your product reads and writes. Unternehmen Online is a delivery channel: your customer's documents go in, and their tax advisor takes them from there. Three things follow from that, and Maesn absorbs each one.
The advisor picks it up there
What you send lands in your customer's own Unternehmen Online environment, which is where their tax advisor already works. That replaces the export, the email and the manual upload, and it is the reason the integration is worth building at all.
The long token, handled
DATEV issues a short token to list the companies and a long one, valid two years, to work with. Maesn runs both target systems behind one interface, so your code sees a single account key rather than a two-stage login it has to orchestrate.
No consulting package to book
The documentation is explicit: client credentials, sandbox access and the approval of your integration all run through Maesn, and there is no need to book consulting packages with DATEV. That is the certified partnership doing the work.
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.
Unternehmen Online is one of two DATEV systems reachable through Maesn, and which one a use case needs is decided by direction rather than preference: documents go in here, bookings are recorded next door. The DATEV overview lays out the services, the certification and the marketplace across both, so this page can stay on the one your customer actually uploads into.
A short call is usually enough to tell whether Maesn fits your use case.
HubSpot reaches DATEV without building for DATEV
HubSpot syncs customer data, invoices and payment reminders into the accounting systems its DACH customers run, DATEV among them, for hundreds of those customers, without building or maintaining a single one of those integrations in-house.
“We integrate German accounting systems and rely on Maesn as a trusted enabler - ensuring seamless data flow, full compliance, stronger partnerships, and efficient, reliable financial processes that support our growth.”
Three reasons to reach the DATEV Unternehmen Online API through Maesn
With DATEV almost all of the work sits before the request: everything that has to be true for it to be allowed, and all of it German, certified and configured by someone who is not you.
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
5 objects readable and 4 writable today, with only 2 combinations in the entire matrix left on request. What is on this page is the whole truth rather than a selection, and on this system it is unusually final: read it as an answer.
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 sibling system inside DATEV is one of them.
One Unternehmen Online token, two years, one company
DATEV authenticates through its own login, with SmartCard or SmartLogin as the access medium, and Maesn puts the whole thing behind the same interface as every other system. What is specific here is what the flow has to end with: a long access token that is valid for two years and only for calls that name the company it was issued for.
- Long access token
- Valid two years, bound to one company
One account key in your code. The two DATEV target systems and the company binding stay on our side.
- The interactive flow
- Your customer logs in, picks their company from the list DATEV returns, and confirms. The company ID is stored on the connection, so nothing downstream has to carry it. This is the route the documentation puts first.
- The manual route
- Three steps you drive yourself: authenticate against the short-token system, fetch the company list, then authenticate again against the long-token system with the company you chose. More work, and more control over the interface your customer sees.
The two-year lifetime is the useful part and the binding is the catch: a long token authenticates calls for the company it was issued for and no other. Model a connection per company from the start and the second one costs nothing; model it per customer and it is a migration.
- 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, so one has to be selected. That choice is what the long token is bound to, which is why a customer with two companies is two connections rather than one with a switch.
- 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.
An access medium your customer holds in their hand, and a token exchange that runs in two stages, are exactly the kind of difference that turns into a per-system implementation. Unified authentication is what keeps it out of your code: the access medium, the company selection and the token lifetime are handled on our side, and what your product holds is the same account key it holds for a system that authenticates with a password.
No Unternehmen Online events, an async task instead
No object here carries a native event, and only two cells in the entire matrix are marked on request, both of them webhooks. On a system you write to rather than read from, that matters less than it sounds: what you need to know is whether the document you sent arrived, and that is a question about your own request.
Nothing. There is no native event on any object here, and the reference data you do read, the accounts, the fiscal years, the tax rates and the users, changes rarely enough that a schedule is the right instrument for it anyway.
The async task. All four objects you can create here are written through endpoints that run asynchronously, and each call returns a taskId you read back on GET /asyncTask. That is the acknowledgement a webhook would have carried, on a path that exists today.
This is the shape of a delivery channel: you own the state, DATEV owns the destination, and the only thing you need back from it is confirmation. Treat the task as part of the write rather than as an afterthought and the integration has no polling loop at all.
A missing webhook is usually a gap you have to fill. Here it is the wrong question, because a document upload is a long-running operation and the answer you need is about your own request rather than about someone else’s change. How asynchronous work is modelled covers the task object, the identifier it comes back on and what a partial response looks like, and it is the same mechanism on every system that has long-running writes rather than a DATEV special case.
What has to be true inside your customer's DATEV
On this system the conditions live in your customer's account rather than in yours, and the documentation names them precisely. Worth walking through with the first customer before the sprint rather than during it.
- A DATEV instance with a fiscal year, and Unternehmen Online enabled
- The fiscal year has to exist and Unternehmen Online has to be enabled for that company, the Mandant. Both are settings in your customer's DATEV, not something an API call can create.
- Belege Online in standard or erweitert
- The DATEV app Belege Online has to be activated, and which of the two modes you need depends on the service your use case runs on. A request that is right in every other respect still comes back refused when the mode is wrong.
- An access medium, with at least standard rights
- A SmartCard or SmartLogin for secure access to the company, held by a person who has at least standard access rights for Belege Online. The rights are configured in DATEV Rechteverwaltung Online, which is the tax advisor's tool rather than yours.
- A real instance to test against
- The documentation calls testing against a live production environment both recommended and necessary before you offer the feature, and that instance needs the service subscriptions your use case uses. Maesn provides the sandbox for building; this step is about the last mile before your first customer.
Bring your use case and we will tell you which services and rights it needs.
What the Unternehmen Online API exposes today
Every object and operation Maesn exposes for DATEV Unternehmen Online. 5 objects are readable and 4 writable today, no object sends a native event, and only 2 combinations in the whole matrix are available on request.
Showing 9 of 37 objects
| Object | Read | Create | Update | Delete | Webhook |
|---|---|---|---|---|---|
| Accounts | |||||
| Async task | |||||
| Booking proposals | |||||
| Expenses | |||||
| Files | |||||
| Fiscal years | |||||
| Tax rates | |||||
| Transactions | |||||
| Users |
- Supported
- live today
- On demand
- available on request
- Not available
- not offered by DATEV Unternehmen Online
What you write, you do not read back
Read and write do not overlap here at all: you read accounts, fiscal years, tax rates, users and the async task, and you write booking proposals, expenses, files and transactions. Your system stays the record of what you sent.
There is almost nothing to request
Two combinations in the whole matrix are marked on demand, and both are webhooks. On every other system in this catalogue that column is where a use case gets unblocked; here the matrix is close to final, so read it as an answer rather than as a starting point.
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 this matrix is smaller than most here for a reason that is not a shortcoming: a delivery channel has fewer objects than a ledger. What you send still arrives in the shared common data model, so the expense you post here has the same shape as the expense you post into a system ten times its size, and the code you write once is the code you point somewhere else.
The other half of a matrix is what it does not carry, and here that is deliberate rather than accidental. Nothing that gets booked can be read back out, because booking is not what this system does: that happens in DATEV Rechnungswesen, which is where the export service reads journal entries, balances and open items. DATEV also runs an e-invoicing platform, which is a target system of its own and has its own integration guide. Between the three, the question to answer early is not which one you prefer but which one holds the data your use case is about.
The matrix is close to final on this system, so it is worth checking your use case against it early.
