In short and in plain language
Your tax office may use DATEV. One DATEV service sends invoices from your shop to the office. This service ends on 31 December 2026.
First check if your shop uses this service. Ask your tax office too. A service with a similar name will keep running.
The new way sends ready bookings. So agree with the office first on how to book each sale.
Test the new way for one month. Then turn off the old way. This way no invoice is booked twice.
On 31 December 2026 DATEV switches off its Rechnungsdatenservice 2.0, the invoice data service (DATEV). Anyone who has been sending invoice data from a shop or ERP system to their tax adviser through this service needs a different route by then – and first has to establish whether the data already sent has been fully collected. The number of businesses affected is limited; DATEV itself cites low usage figures as a reason for the shutdown (DATEV). For every business that is affected, the deadline is still a hard one: after it, invoices no longer reach the books by this route. This article shows how an inventory of your data flows tells you whether you are affected, which routes can replace the service, what changes in account assignment when you move to the Buchungsdatenservice (booking data service), and how a parallel month and a cut-off date prevent invoices from being booked twice. How custom shop and ERP connections move to the new route is shown in the last section.
Key takeaways
- DATEV discontinues Rechnungsdatenservice 2.0 (item no. 92900) on 31 December 2026; it could no longer be ordered from 1 January 2026, and sent invoice data can only be retrieved until 31 December 2026 (DATEV).
- The similarly named Rechnungsdatenservice 1.0 continues to run (DATEV). Whether you are affected is shown by an inventory of the data flows between shop, ERP and tax adviser, not by the product name alone.
- In JTL-Wawi, Rechnungsdatenservice 2.0 has not been usable since 1 March 2026 (JTL-Guide). JTL users check whether the switch is complete and whether invoice data from January and February 2026 has been fully collected.
- The Buchungsdatenservice transfers complete booking records, master data and document images (DATEV). Account assignment therefore moves from the tax adviser into the upstream system and has to be agreed with the adviser beforehand.
- A cut-off date based on the document date and a parallel month in which the adviser reconciles document counts and totals per tax code prevent the same invoice from being booked twice via both routes.
- Accounting vouchers must be retained for eight years (§ 147 Abs. 3 AO). Transfer logs and assignment rules of the old route should therefore be archived before the module is switched off.
What DATEV discontinues and what keeps running
The notice is short and clear: DATEV discontinues the product DATEV Rechnungsdatenservice 2.0, item number 92900, completely on 31 December 2026 (DATEV). New orders have not been possible since 1 January 2026 (DATEV). For existing users the third sentence of the notice matters most: sent invoice data can only be retrieved in the accounting programs until 31 December 2026, and DATEV explicitly asks users to collect all transferred invoice data by then (DATEV). Whatever is still sitting in the DATEV cloud after that date no longer reaches the books by this route.
The service was built for a specific purpose. According to DATEV, Rechnungsdatenservice 2.0 sends structured invoice data, depending on the upstream system, to the DATEV cloud, from where it is loaded into the accounting program (DATEV). Account assignment stayed with the tax adviser: JTL states for its connector that subsequent processing by the tax adviser is necessary in every case (JTL-Guide). It is precisely this point that makes the switch more than an exchange of credentials, as the following sections show.
One distinction matters: the similarly named Rechnungsdatenservice 1.0 is not affected by the shutdown (DATEV). It transfers structured document data and document images to DATEV Unternehmen online, where document records for Belege online and, once they are released, posting suggestions for the accounting programs are created (DATEV). Anyone who reads "Rechnungsdatenservice" in a shop or ERP setting should therefore check the version number first, before starting a project. DATEV names portfolio development and low usage figures as the reasons for the shutdown (DATEV). The overview below sets the four data services side by side that are easily confused in this context; item numbers and descriptions come from the product pages (DATEV), the note on optional images for Rechnungsdatenservice 2.0 from the JTL manual (JTL-Guide).
| Data service | What is transferred | Where it arrives at DATEV | Status |
|---|---|---|---|
| Rechnungsdatenservice 2.0 (item no. 92900) | structured invoice data, images optional | the tax adviser's accounting program | ends on 31 December 2026 |
| Rechnungsdatenservice 1.0 (item no. 92222) | structured document data with document images | Belege online in DATEV Unternehmen online, turned into posting suggestions | not affected |
| Buchungsdatenservice (item no. 91000) | booking data, master data, document images | Kanzlei-Rechnungswesen as complete booking records, images in Belege online | target of the switch for JTL according to DATEV |
| Belegbilderservice Rechnungswesen (item no. 92902) | digital documents without booking data | Belege online | separate service, still offered |
1.0 or 2.0? Check the version before the project
Am I affected? An inventory of the data flows
The question cannot be answered by looking at the shop alone, because the document route to the tax adviser often runs through several stations: the shop takes the order, the ERP system writes the invoice, an add-on module or a custom connector transfers the data, and the adviser collects it in DATEV. For each of these stations, write down which document types it handles and which service it sends through. Only this list shows whether Rechnungsdatenservice 2.0 is involved at all and which documents depend on it. These questions belong in the inventory:
- Which system writes outgoing invoices and credit notes: the shop, the ERP system or a separate invoicing module?
- Which DATEV data service do these documents go through today, and which version number is shown in the settings?
- Which data services has the tax adviser set up for your client number, and which of them are actively used?
- Are document images sent along, or does the adviser fetch the invoice PDFs through a second channel?
- Are there channels whose documents take a different route, such as a marketplace, a second shop or a physical store?
- When was the last transfer, and has all sent data been collected and processed by the adviser?
The answers to the last two questions are often the most surprising. Channels that were connected later not infrequently bypass the central accounting connection. And only the tax adviser knows whether all data has been collected, because they can see in their accounting program what has arrived. In practice it helps to put one month of invoice numbers from the upstream system next to the documents processed in DATEV: gaps then show up as missing numbers, duplicates as doubles.
Special case JTL-Wawi: the deadline is already behind you
For JTL users the situation differs from everyone else's. DATEV planned the switch to the Buchungsdatenservice for customers of the upstream system JTL as early as the first quarter of 2026 (DATEV). JTL is more explicit in its own manual: DATEV changed the authentication for Rechnungsdatenservice 2.0 as of 28 February 2026, so the service has not been usable in JTL-Wawi since 1 March 2026 (JTL-Guide). JTL users therefore do not face an open migration until year end. Instead, they check two things: has the switch to the new route actually been completed, and has the data from the period before fully reached the tax adviser?
The second question is the trickier one. JTL asked users to back up all necessary data by 28 February 2026 (JTL-Guide). Invoice data from January and February 2026 that was sent but not yet retrieved by the adviser can, according to DATEV, be retrieved in the accounting programs until 31 December 2026 (DATEV) – and not after that. Matching the invoice numbers of both months against what has been booked in DATEV costs little and closes this gap. How to plan the connection between JTL-Wawi and the shop itself is described in the article Connecting JTL-Wawi to your online shop; for the implementation there is our JTL-Wawi shop integration.
From invoice record to booking record: what shifts
The Buchungsdatenservice works on a different principle from the service it replaces for JTL. According to DATEV, it transfers booking data, master data and the associated document images from software solutions via the DATEV cloud to DATEV Kanzlei-Rechnungswesen or DATEV Mittelstand Faktura mit Rechnungswesen (DATEV). There the data can be retrieved as complete booking records; the document images are stored in Belege online and automatically linked to the booking record (DATEV).
The difference lies in the word "complete". With Rechnungsdatenservice 2.0, the upstream system delivered invoice data and the tax adviser turned it into bookings. With the Buchungsdatenservice, the upstream system delivers the booking itself: revenue account, contra account, tax code, amount, document date and invoice number. The decision on how a sale is booked is no longer made at the adviser's desk but in the rules of the interface. Anyone who does not agree these rules with the adviser beforehand receives batches that are transferred cleanly but assigned to the wrong accounts. Four areas decide whether the batches go through without rework:
Revenue accounts
The tax adviser decides which product group, channel and tax rate go to which revenue account. The interface applies this per invoice line, not per invoice total.
Tax codes
Domestic sales, intra-community supplies, One-Stop-Shop sales and exports each need their own codes. The adviser specifies them, the upstream system detects the case from customer data and delivery country.
Customer accounts
Whether consumers are booked to a collective debtor account and business customers to their own debtor accounts determines how open items are reconciled. The Buchungsdatenservice can also transfer debtor master data (DATEV).
Document images
The invoice document is sent along as a document image and linked to the booking in Belege online (DATEV). If the image is missing, the adviser has to look for it through a second channel.
Then there is the chart of accounts. When its connector is set up, JTL asks whether bookings use SKR03 or SKR04 (JTL-Guide), and every custom connection has to answer the same question before the first revenue account is mapped. How field mappings between systems are documented in a traceable way is shown in the article on data mapping between ERP and shop. The basics of automated hand-over to DATEV, with formats, account mapping and payment matching, are covered in the article DATEV integration in e-commerce.
The alternatives compared
For the upstream system JTL, for example, DATEV names the Buchungsdatenservice as the target of the switch (DATEV). It is not the only way to get documents from the shop to the tax adviser, though. Which route fits depends on what the upstream system offers, how many documents arise and how much account assignment the adviser wants to keep doing.
| Route | What arrives at the adviser | Who assigns accounts | Fits when |
|---|---|---|---|
| Buchungsdatenservice | complete booking records, master data, linked document images | the upstream system, following agreed rules | the upstream system offers the service or a custom connector uses it |
| Rechnungsdatenservice 1.0 | document records in Belege online, turned into posting suggestions | the adviser, based on the suggestions | the upstream system supports this service and DATEV Unternehmen online is in use |
| Belegbilderservice Rechnungswesen | digital documents in Belege online | the adviser, entirely | few documents arise and the adviser books them anyway |
| File in DATEV format | booking batch as a file, imported by the adviser | the upstream system, hand-over done manually | a stopgap is needed until automatic transfer is in place |
According to DATEV, the Belegbilderservice is an interface for exchanging digital documents between selected ERP cloud solutions and Belege online (DATEV); it requires a DATEV Unternehmen online contract and a Belege online data store (DATEV). For a shop with a significant invoice volume it pushes all account assignment back to the tax adviser. The file export in DATEV format is the robust fallback: JTL names an export of the data for DATEV in its manual as an alternative and advises users to agree with their tax adviser which data has to be exported (JTL-Guide). In the long run, however, the file route depends on a person who exports, hands over the file and checks the import – exactly the manual work a data service is meant to take away.
Not every upstream system offers every service
Agree with the tax adviser before the first batch flows
The Buchungsdatenservice is usually ordered through the tax adviser: the product page points out that this data service is activated directly in the DATEV Arbeitsplatz (DATEV). According to DATEV, businesses can also set up data services themselves (DATEV), but the account assignment rules need the adviser either way. JTL describes the usual sequence from the user's side. The tax adviser orders the Buchungsdatenservice through MyDATEV client registration; after that, setting it up in the upstream system requires the adviser's Beraternummer (adviser number) and the Mandantennummer (client number) (JTL-Guide). Each of the two numbers has at most 7 characters (JTL-Guide); DATEV assigns the adviser number, the adviser assigns the client number (JTL-Guide). Before anything flows technically, these points belong on the agenda of the alignment meeting:
- Chart of accounts (SKR03 or SKR04) and the list of revenue accounts per product group, channel and tax rate.
- Tax codes for domestic sales, intra-community supplies, One-Stop-Shop sales and exports, each with the rule by which the upstream system recognises the case.
- Customer accounts: a collective debtor for consumers, individual debtors for business customers with payment terms, and which system assigns the debtor numbers.
- Credit notes, cancellations and partial invoices as separate documents referring to the original invoice, not as changes to a booking that has already been transferred.
- Transfer rhythm: daily, weekly or at month end, aligned with the advance VAT return.
- Cut-off date and the parallel month: who approves, who switches off the old route and who collects the remaining data.
The rhythm is not a detail. DATEV explicitly links its data services to booking at shorter and regular intervals (DATEV). An adviser who used to rework invoice data once a month plans their work differently when finished batches arrive every day. Just as important is the question of who changes the rules when a new channel, product group or delivery country is added. The agreed account assignment matrix belongs in the process documentation; what an interface has to describe there is covered in the article on GoBD process documentation for ERP-shop interfaces.
Collective or individual debtor accounts
Parallel month and cut-off: no invoice booked twice
The biggest risk during the switch is not an outage but a duplicate. If the old route delivers an invoice as an invoice record and the new route delivers the same invoice as a finished booking record, the revenue appears twice in the books, and so does the VAT. Because the two routes arrive at different places in DATEV, this is not necessarily noticed right away. Two tools prevent it: a cut-off date that assigns every document unambiguously to one route, and a parallel month that tests the new route before it counts.
The switch in four steps
- 1
Check data flows
Inventory of all stations from shop to tax adviser: which document types, which service, which version and what has been collected so far.
- 2
Adviser activates service
The tax adviser orders the Buchungsdatenservice for the client number and agrees chart of accounts, revenue accounts, tax codes and customer accounts with you.
- 3
Parallel month
The new route delivers a closed month as a trial. The adviser compares document count and totals per tax code with the month already booked, before anything is finalised.
- 4
Retire old route
From the cut-off date only the new route sends. The old service is deactivated in the upstream system; the adviser collects remaining data by 31 December 2026 (DATEV).
The cut-off date depends on the document date, not on the transfer date. All invoices dated before the cut-off go through the old route or, if it is no longer available, through a one-off catch-up run that the adviser explicitly expects. All invoices from the cut-off date onwards go exclusively through the new route. Using the first day of a month as the cut-off makes reconciliation with the advance VAT return easier, because no month is split across two routes.
There are two variants of the parallel month. If the old route is still running, the new route transfers a month that the adviser has already processed, and the adviser compares both results side by side before discarding the trial batch. If it no longer runs, as in JTL-Wawi since 1 March 2026 (JTL-Guide), the benchmark is the outgoing invoice register of the upstream system: number of invoices and credit notes, net total and tax per tax rate. In both cases the cut-off only goes live once document count and totals match and the adviser has confirmed the account assignment on a sample basis.
Technically, the interface needs a transfer journal for this: for each document it records which route it was sent through, when, and with what result. The invoice number serves as the business key; a second transfer of the same number is rejected instead of sent. Before switching over, a simple query shows whether there are documents from the cut-off date onwards that have already gone through the old route:
-- Documents from the cut-off date that were already sent via the old route
SELECT invoice_number, document_date, route, sent_at
FROM transfer_journal
WHERE document_date >= :cutoff
AND route = 'rechnungsdatenservice_2_0'
ORDER BY document_date;If the query returns rows, the cut-off date is set incorrectly or the old route is still active. How retries are built without duplicates is described in the article on idempotency and retry strategies. And if you first need to decide whether the shop or the ERP system writes the invoice in the first place, the decision matrix is in the article Invoice from shop or ERP?.
Collecting and retaining legacy data
Switching off the old route does not finish the job. DATEV asks users to collect all transferred invoice data by 31 December 2026 (DATEV). This is the tax adviser's task, because retrieval happens in their accounting program. A short written reconciliation that puts the last invoice number transferred from the upstream system next to the last invoice number processed in DATEV closes the matter in a verifiable way.
Retention periods continue to run alongside. Accounting vouchers must be kept for eight years, books and records for ten years (§ 147 Abs. 3 AO). Stored records must be available at all times during the retention period, made readable without delay and be machine-evaluable (§ 147 Abs. 2 AO). For the switch this means: the transfer logs of the old route, the configuration of the old interface and the assignment rules valid until then should be archived before the module is uninstalled. Anyone who later has to show how an invoice from 2026 reached the books needs exactly these records. Which data has to stay where and for how long, and when it may be deleted, is covered in the article on the deletion concept across system boundaries.
Design the new route for e-invoicing from the start
The switch comes at a time when the invoice format in B2B business is changing as well. For supplies to other businesses in Germany, the invoice generally has to be issued as an electronic invoice in a structured format (§ 14 Abs. 2 UStG). For supplies made in 2027, paper and other electronic formats remain permitted only if the previous year's total turnover did not exceed 800,000 euros; in addition, a special rule for EDI procedures applies until the end of 2027 (§ 27 Abs. 38 UStG). For supplies from 1 January 2028 onwards, the transitional rule provides no further exception (§ 27 Abs. 38 UStG).
For the new data route this means: for B2B invoices, the document image that goes to the adviser together with the booking should come from the same source as the e-invoice sent to the customer and carry the same invoice number, rather than being created separately. How the e-invoice is filed in DATEV therefore belongs on the agenda of the alignment meeting. Anyone building the account assignment layer now should design it to take the invoice from the same source as the dispatch to the customer. The framework for issuing invoices is described in the article E-invoice mandate 2027; the implementation in the shop is covered by our e-invoicing integration.
Moving custom shop and ERP connections to the new route
For standard systems, vendors ship their own routes. The situation is different when the document flow runs through a custom connector, several shops or marketplaces come together, or the account assignment rules go beyond what a standard module covers. Then account assignment is the real work and the transfer only the last step. An integration layer reads invoices, credit notes and cancellations from the shop and the ERP system, applies the rules agreed with the tax adviser, produces booking records in DATEV format, links the document image and records in the transfer journal what has been sent.
This is exactly what our DATEV integration covers: rule-based account assignment by product group, customer type and delivery country, hand-over via the DATEV interface or as a booking batch file depending on the target product, a status in the shop showing which documents have been transferred, and a test on a DATEV test environment before the cut-off date goes live. If the data runs through several systems, middleware bundles the streams; if the invoice is written by the ERP system, the inventory system integration is the starting point. An overview of all building blocks is on our services page.
The timeline to the turn of the year
What else is due at the interfaces around the turn of the year is summarised in the article Stocktaking and year end. Whether you are affected by the end of Rechnungsdatenservice 2.0 can usually be clarified in a short conversation looking at the upstream system, document types and tax adviser. Once it is clear that the route has to change, the project follows the same sequence as above: check data flows, adviser activates the service, parallel month, retire the old route. Contact details and ways to reach us are on our contact page.
Related Articles
DATEV Connection in E-Commerce: Automated Accounting
DATEV connection for online stores: automatically transfer invoices, credit notes and payments. Posting batches, XML documents and API integration.
GoBD Process Documentation for ERP Shop Interfaces
The GoBD require process documentation for every bookkeeping-relevant IT system. How to document the document path of your ERP shop interfaces properly.
Invoice from shop or ERP? Setting the leading system
Shop or ERP: which system issues the invoice and assigns the number? A decision matrix for partial delivery, cancellations, marketplaces and e-invoicing.