Magento DATEV: Provide Revenue, Payments and Documents From the Shop for Accounting

DATEV is a cooperative company that offers software and services for tax advisers, companies and their accounting. For an online merchant DATEV is usually the side of the tax adviser: bookings are recorded there, VAT is calculated and annual statements are created. Your shop supplies the raw data for it, that is revenue, taxes, payments and documents.

That distinguishes Magento DATEV from the connection to an ERP. It is less about articles and stock and more about data that is correct for accounting: which revenue belongs on which account, which tax key applies, how are payment fees and refunds booked? Your tax adviser defines these rules, and we implement them technically.

Magento DATEV therefore begins with a conversation of three: your accounting or tax adviser, you and us. There we clarify in which form the data should arrive, how often, and which accounts and tax keys apply. Only then can it be said seriously which way fits.

It is also important whether your shop delivers directly to DATEV or whether the data first lands in an invoicing program such as Lexware or WISO and is passed on from there. Both are common. We set up the integration as your accounting works instead of adapting your processes to the interface.

Which data flows in Magento DATEV you define with your tax adviser and us in the inventory. Typically there are five areas.

Not every Magento DATEV project needs all five areas. Often it begins with revenue and payments and later grows by documents and debtors. This way you see results quickly and can use the budget in stages.

The table shows a typical pattern. In your business it may differ, and that is exactly what we clarify in the inventory with your tax adviser.

With Magento DATEV a clear rule on responsibility prevents most disputes: the tax adviser defines accounts and tax keys, the shop delivers the data, and the log shows what was handed over. We document the assignment so that nothing is lost if the tax adviser changes. The point of booking also belongs here: whether booking happens after order, payment or shipping is decided by your tax adviser.

For Magento DATEV, DATEV names several ways. The basis is the DATEV format, a file format for structured booking data. The booking data service builds on it, which hands over structured booking data and the associated digital documents from partner programs into the accounting of DATEV. There is also the invoice data service, which hands over PDF documents with structured data into DATEV Unternehmen online and requires extended processing there, as well as a programming interface for data exchange in the cloud.

The simplest variant is an export as a file in which documents do not go along and every handover needs a manual step. For a shop with more than a few orders a way that hands over bookings and documents automatically usually pays off. Which way is possible for you depends on the DATEV products of your tax adviser and their settings.

DATEV itself points out that it checks whether the output file of a partner program is read in correctly but cannot guarantee that the range of functions meets your requirements. That is one more reason to test the integration together with your tax adviser. These statements come from DATEV pages and partner pages and can change, so we check them before the quote.

For the handover of shop data to DATEV there are add-on products from third-party vendors, and many accounting programs export in DATEV formats themselves. Often the most economical way is to create invoices in a program such as Lexware, Sage or WISO and hand them over to DATEV from there. Whether an existing way covers your requirements we check honestly before a decision. With every way ask who maintains it when DATEV changes formats.

An individual development for Magento DATEV pays off if your processes deviate from the standard: several payment providers with their own statements, mixed tax rates, foreign sales with special rules or documents that should arrive in a certain format. It is more expensive at the start but fits exactly. Include the care as well, because tax rules change.

If more than two systems are connected, for example shop, merchandise management and accounting, a middleware can make sense. The decision aid is in the guide to ERP integration.

On the Magento side we build the integration as its own module according to the standards of the system, without interventions in the core. The module uses the interfaces and queues of Magento so that transfers run in the background and the shop does not become slower for visitors. Orders are placed in a queue on arrival and processed there until the ERP has confirmed them.

Magento maps revenue, taxes, shipping costs, payments and refunds with its own functions, and these are exactly the data we prepare for accounting. Where possible we use the standard functions of Magento instead of inventing our own tables. That keeps the shop update-capable and lets other developers join in later.

In the admin you see what was transferred: a log shows date, record and result, with a filter for errors. For the peculiarities of DATEV we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With DATEV the assignment to accounts and tax keys counts. For this Magento DATEV gets settings in the admin in which your tax adviser or accounting assigns payment methods, shipping methods and tax classes to the agreed accounts without every change needing a development.

We see these points again and again in projects. They can be planned if they are known early.

• Accounts and tax keys

  The assignment is guessed instead of defined with the tax adviser, and bookings land wrongly.

• Payment fees

  Fees of the payment providers are missing in the bookings and lead to differences.

• Foreign sales

  Special tax cases are not considered in the concept.

• Documents missing

  The chosen way does not transfer PDFs, and accounting searches for documents by hand.

• Time of booking

  Revenue is booked at the order date instead of the agreed point in time.

• Missing feedback

  Errors in the takeover into DATEV are noticed only at the month-end closing.

An integration connects two systems with business data, so clear rules apply. The exchange runs encrypted, credentials do not lie in the source code but in the protected configuration, and the integration receives only the rights it needs. Access belongs to a separate service account, never to a private account of a person.

When testing we work with test data or anonymized data as far as possible. As soon as developers get access to personal data, for example customer accounts or orders from DATEV, an agreement on commissioned data processing is needed. We clarify that before the start so that you are legally well set up.

The log of the integration contains what is necessary for operation but no credentials and no unnecessary personal data. Retention periods are defined with you. These notes are not legal advice, the concrete arrangement depends on your company.

We keep the start deliberately short so that you quickly know whether and how the integration is feasible.

The following constellations are examples from the practice of Magento DATEV projects, not statements about particular customers. The first is a small merchant who sends a table of revenue to the tax adviser every month. A Magento DATEV export turns this into a clean file in the agreed format without anyone having to copy figures. That saves time at every month-end closing.

The second constellation is a merchant with several payment providers. The challenge lies in the reconciliation: payments, fees and payouts must be assigned to orders so that open items are correct. We map the rules agreed with the tax adviser and test them with real statements.

The third constellation is a business with sales to several countries. Here tax cases decide about the booking, and the rules must be fixed before the start. We implement them as your tax adviser specifies and record which assumptions apply.

In all three cases a small trial pays off: before the integration runs productively, a few typical orders are handed over as test bookings, including one with several tax rates, one with a foreign delivery and one with a refund. Your tax adviser checks the result, and only then does operation start. This way assignment errors show up early and cost little.

An interface is not a one-off project but ongoing operation. After the start a log monitors every transfer: what was transferred when, what failed, what is repeated? Errors that cannot be fixed automatically are reported visibly so that nobody learns of them only through a customer complaint.

Updates change the situation. A Magento update, a new state at DATEV and your tax adviser or a change of the vendor interface can affect the integration. Therefore the planning includes an agreement on how updates are tested and who approves them. Ongoing care can be regulated through a maintenance contract that covers monitoring, updates and error fixing.

Documentation is part of the delivery. You receive a description of the data flows, the assignments and the rules for special cases so that your team or another provider understands the integration and can continue it. Source code and access stay with you.

A flat figure for Magento DATEV would be unreliable because the effort depends on your constellation. It is determined by the number of data flows, the quality of the data in DATEV, the number of special cases with tax keys, revenue accounts and foreign orders and the required timeliness. A data flow in one direction is built much faster than a synchronization in both directions with conflict rules.

We work with an open hourly rate of 30 euros net, without emergency surcharge. After the inventory you receive a written estimate that lists the data flows individually so that you can control scope and order yourself. For clearly defined packages a fixed price is also possible. All prices are on the page pricing.

Besides the development, include the running items: hosting, maintenance and, where applicable, licenses or fees for DATEV and for additional services. We show these items separately in the estimate so that you can compare quotes over several years.

An honest offer includes naming the limits. We do not sell a ready-made connector off the shelf but develop Magento DATEV project by project according to your processes. That means: we implement exactly what you need, but not in a day and not for a flat price that cannot be calculated beforehand.

We are a web agency in which fixed freelancers work together, all from home offices. We are not a large agency with a hundred employees and cannot take on every project at every time. We tell you early whether and when we have capacity. We name customers only with their consent, and in the first conversation we gladly talk about comparable constellations.

We give no legal advice. Questions about commissioned data processing, data protection and the license terms of DATEV you clarify with your legal adviser and the vendor. What is technically possible depends on version, operation and license of your system and is checked in the inventory.