DATEV Unternehmen Online or Rechnungswesen: One object is writable on both

DATEV Unternehmen Online is the cloud platform where a German business and its tax advisor exchange receipts and accounting data. DATEV Rechnungswesen is the application where the booking is finally recorded, and it runs on a provider’s server or on the customer’s own rather than as a cloud product you sign up for.

Which one a company has follows from who does the bookkeeping. A business that hands it to its tax advisor works in Unternehmen Online and the advisor works in Rechnungswesen. A business that books in house has Rechnungswesen and still has Unternehmen Online, as the cloud route into its own instance.

Neither case stops an integration from reaching Rechnungswesen. Even where only Unternehmen Online is in use, the instance running at the customer’s tax advisor is reachable, identified through the advisor and client identification. So the question is not which product a customer owns. It is which one holds the data your feature is about.

This article answers that one question. How to build against either product once you have chosen is a subject of its own, and each has its own guide: the Unternehmen Online guide covers asynchronous writes and the two-stage token, the Rechnungswesen guide covers three target systems and two token lifetimes.

The commercial and coverage detail per product sits on the DATEV Unternehmen Online API page and the DATEV Rechnungswesen API page, and the vendor level, meaning the full list of data services and the partner status, sits one level up on the DATEV overview.

Unternehmen Online accepts 4 objects and Rechnungswesen accepts 3, and the two lists share 1: Files. That overlap is not a choice you get to make. A document always goes to Unternehmen Online, including when the booking it belongs to is being written into Rechnungswesen, so the two products share the row because they share a station rather than because the payload can go either way.

It also means the first mapping most teams attempt does not exist on either product. An invoice in your system does not become an invoice in DATEV: Invoices, Bills and Credit notes are not writable objects here, and the document travels as a file while the data about it travels as something the target product recognises.

What that something is differs, and this is the row that decides most builds. A booking proposal is a suggestion for the advisor to review, and only Unternehmen Online takes one. A journal entry is a finished posting, and only Rechnungswesen takes one.

Files · create is enabled on 4 of the 29 systems in our catalogue, and two of those 4 are these two DATEV products. Delivering a document to DATEV is therefore unusually well supported. Deciding what the document means is where the two products diverge.

Through Maesn both products answer on one interface, so the choice below is a target and a payload rather than two integrations. You post the common data model and the translation into the shape each product expects happens on our side.

On Rechnungswesen, and under a different name. The German personal account, the Personenkonto, is Contacts in our model. It can be created and updated in place on Rechnungswesen, it cannot be read back, and on Unternehmen Online it does not exist at all.

Three vocabularies meet on this one object, and they all mean the same record. What German accounting calls a Debitor or a Kreditor is what most product teams call a customer or a supplier, and both of them reach DATEV through Contacts. The distinction between the two is the account number, not the object: a Debitor sits in one number range and a Kreditor in another, and both are written as a Personenkonto.

That is why Customers and Suppliers are not separate objects here, and a team that maps to those two names looks for something that never existed under them. Map to Contacts and the record is there.

The consequence shows up in real projects rather than in a table. A product that synchronises supplier master data and also delivers incoming invoices has two halves that land on two different products: the invoice reaches Unternehmen Online as a document plus a proposal, the account reaches Rechnungswesen as a contact.

If your feature is a two-way customer and supplier data sync, the read half of it does not exist on either DATEV product for this object. Plan the one-way version and keep your own record of what you wrote.

Three data services, and you use exactly one per call. The Belegbilderservice takes a document image on its own. The Rechnungsdatenservice 1.0 takes the same image together with its structured data, so the advisor receives a booking proposal instead of a scan to type up. The Buchungsdatenservice takes a finished journal entry.

The first two deliver into Unternehmen Online and end at something a person still has to act on. The third writes into Rechnungswesen and ends at a posting in the ledger. Which one you call follows from what you have: a PDF alone, a PDF with its data, or a booking that is already reconciled on your side.

What happens next is a step your call does not make. The structured data does not continue into Rechnungswesen on its own: it is provided to the DATEV data centre from the Unternehmen Online interface, by the business or by the advisor after the cash ledger has been checked, and it is retrieved into the Rechnungswesen instance from there.

The prerequisites differ per route as well, and all of them live in your customer’s account rather than yours.

Posting a document image needs Unternehmen Online with the Belegbilderservice. Booking proposals need the Rechnungsdatenservice 1.0 instead. Posting journal entries directly needs Rechnungswesen and the Buchungsdatenservice on top.

One prerequisite is easy to attach to the wrong call: the cash ledger that a DATEV user creates by hand as a clearing account belongs to POST /expenses, not to POST /bookingProposals. A booking proposal does not need one.

Each route also has its own file format, and the format follows the destination rather than your preference: which DATEV format belongs to which target is a subject of its own. You never write one of those files yourself. You send JSON to our REST API, and we build the CSV or XML the destination expects.

Rechnungswesen returns 8 objects and Unternehmen Online returns 5. The count matters less than which ones. Both products return Accounts, Async task, Fiscal years, Tax rates, Users, and Accounts in that list is the chart of accounts every booking is posted against, which is the read teams underestimate most often. Rechnungswesen then adds what a reporting or reconciliation product is after: Journal entries, Payment terms, Trial balance.

Journal entries is the one object that makes the round trip. You post a posting and you can query it back, which is what separates a reconciliation feature from a delivery feature and why a reporting product ends up on this product rather than upstream of it.

One condition comes with the read, and it changes a design rather than a call. Only finalised data is available: entries become exportable after the posting batches have been finalised, the Festschreibung, and transferred through DATEV’s standard posting process. A booking that exists in the advisor’s screen is therefore not automatically a booking you can query.

What the export returns and what the finalisation rule does to a sync schedule is covered in the guide to the DATEV Datenservice Export Rechnungswesen. For a product built on the numbers rather than on the documents, that read is the whole reason DATEV is on the roadmap, and financial analysis and forecasting is what teams do with it.

The decision follows from what your product produces rather than from what your customer owns, and each row carries the object state it rests on.

The last row is the one that surprises teams, because an e-invoice looks like an invoice and an invoice looks like accounting. DATEV runs a third target for it, and the E-Rechnungsplattform guide covers what is possible there today and what is not.

Most products end up on both of the two products in this comparison, and that is the normal outcome rather than a sign of a wrong decision. What the table prevents is the other case: building the delivery half against Unternehmen Online, then discovering during a reconciliation feature that the ledger was never readable from there.

Three properties hold for both products and each of them changes a design decision. Only Contacts can be updated in place, and only on Rechnungswesen. No object on either product supports a delete. And no object on either product sends a native event.

The first two follow accounting practice rather than a gap in the interface. A recorded booking is not edited and not removed, it is corrected by a counter booking, which is also how an auditor expects to see it. Building an update path for journal entries is work that would be rejected by the domain even if the endpoint existed.

The third one has a second half that is easy to miss. With no events to subscribe to, the reflex is a schedule, and scheduled reads are fine. What DATEV lists as a DONT, in the section Ökonomie & Ökologie of its interface requirements, is round-the-clock polling with no customer interest behind it. A DONT is not a technical block and nothing rejects the call; it endangers the approval of your integration, which is the expensive kind of problem because it surfaces late.

In practice the line is the reason for the call rather than its frequency. A read that follows something your customer did, or a rule they configured, is what DATEV asks for. A loop that runs every minute on every tenant whether or not anyone is waiting for the data is what it argues against.

Freshness on either product is therefore a product decision, and how event coverage varies across systems is what makes that decision comparable across the rest of your catalogue.

Three things stop being yours once you connect through Maesn, and the rest stays with you. Both halves are worth knowing before you plan the work:

• 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, and that holds for both products. What DATEV approves is an integration rather than a product, and which data services it uses is what defines it. If you later want to be an official DATEV Interface Partner in your own name, we run that process with you and you move onto your own client; the DATEV fees for it are yours, and you keep building in the meantime. The partnership guide covers what DATEV checks and when.
• The formats and the services behind each route. Whether a payload leaves as a document image, as structured XML or as a posting record in DATEV format, and which data service it travels through, is decided here.
• Two products behind one account key shape. Which target system a call belongs to, and the login and token behind it, resolve during the connection instead of in your call sites.

Three things do not move, and two of them are decisions rather than work:

• Which product a feature targets. The object your feature produces narrows that to one answer, and which feature comes first is yours.
• What your interface tells the customer. Delivered is not booked, and a contact you wrote cannot be read back. Both facts are about wording in your product, and no interface can hide them without lying.
• What triggers a call. A customer action or a defensible rule is a product decision, and it is where DATEV’s constraint and your own roadmap have to be reconciled.