Magento Lexware: Bring Invoices, Customers and Payments From the Shop Into Accounting

Several products exist under the name Lexware. Lexware Office is the cloud solution for invoices and accounting that was formerly known as lexoffice. There are also desktop programs, for example for accounting and merchandise management. For the Magento Lexware integration the decisive question is which product and which version you use, because the interfaces differ.

With Lexware Office an open interface is available through which applications exchange data. That is the most convenient way for a shop: invoices, credit notes and contacts can be created automatically instead of being retyped. With the desktop products the options are different, often through file exchange or import functions of the vendor, and have to be checked in the individual case.

Magento Lexware therefore always begins with three questions: which Lexware product do you use, which plan or version, and who in your business works with the data, for example accounting or tax advice? Only then can it be said seriously which way fits and what it costs.

The division of labor is also important: who keeps the accounting in your business, and who checks documents? Some companies let invoices be released directly, others collect them as drafts and check them before closing. Magento Lexware can do both, and we set it up as your accounting works instead of adapting your processes to the interface.

Which data flows in Magento Lexware you define with us in the inventory. Typically there are five areas.

Not every Magento Lexware project needs all five areas. Often it begins with customers, invoices and payment status and later grows by credit notes and articles. 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 Magento Lexware a clear rule on data ownership prevents most disputes. Especially with documents this applies: an invoice arises in one place and is not maintained in two systems. We therefore define which system assigns the invoice number and record the assignment between shop order and document so that every invoice stays traceable. Which account and which tax key belong to which type of order comes from your accounting and not from us, we only implement the requirements technically and document them.

For Magento Lexware the vendor provides a public interface with Lexware Office that is based on the REST principle. According to the vendor page, invoices and credit notes can be read, created and finalized through it, as well as contacts read, created and changed. A notification on events is also provided so that the shop does not have to ask constantly.

According to the vendor the interface is currently available only from a higher plan of Lexware Office. That matters for the planning because it can mean additional costs for your plan. The terms of use and access data are regulated by the vendor, and before the quote we check which level and which terms apply to you because both can change.

For Lexware products without this interface other ways remain: a file exchange, an import function of the vendor or a connection through DATEV if your tax adviser uses the format. Lexware itself names an interface to the DATEV Buchungsdatenservice for this. Which way makes the most sense for you is shown by the inventory.

For the connection of Magento with Lexware there are add-on products from third-party vendors. Whether one of them fits your process we check honestly before a decision. If an existing product covers your requirements, it is often the more economical choice, and we will tell you so. With every ready-made product pay attention to how it handles tax rates, credit notes and foreign orders. Also ask who maintains the solution when tax rules change.

An individual development for Magento Lexware pays off if your processes deviate from the standard: mixed tax rates, purchase on invoice with a payment term per customer, several payment providers, partial deliveries with partial invoices or special document texts. It is more expensive at the start but fits exactly.

A middleware pays off if more than two systems are connected, for example shop, merchandise management and accounting. 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 invoices, credit notes and payments with its own functions, and these are exactly the documents we pass on to 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 Lexware we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With Lexware it also matters that documents there are no longer freely changeable after completion. Magento Lexware therefore creates invoices only when order, payment and tax are settled in the shop, and treats corrections as a separate credit note instead of a change.

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

• Tax rates and foreign orders

  Different tax rates, deliveries abroad and reverse-charge cases are not considered in the concept.

• Two invoice numbers

  Shop and accounting both assign a number, and nobody knows which one applies.

• Corrections to documents

  A completed invoice is changed instead of creating a credit note.

• Payment fees

  Fees of payment providers do not appear in accounting and lead to differences.

• Plan limits

  The interface is not included in the booked plan and is noticed late.

• Missing monitoring

  A failed transfer is 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 Lexware, 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 Lexware projects, not statements about particular customers. The first is a small merchant who receives a few orders daily and has so far created invoices by hand. Here it is about the simplest way: customer, invoice and payment status are transferred automatically, and accounting only looks at the log.

The second constellation is a merchant with company customers who buy on invoice. Payment terms, VAT identification numbers and credit limits come into play, and the invoice is to arise only after delivery. We define with you at which moment the document is created.

The third constellation is a business with deliveries to several countries. The challenge lies in the tax rates and in the question which rules apply to which order. We map the rules agreed with your tax advice and test them with real examples before the first document arises live.

In all three cases a small trial pays off: before the integration runs productively, a few typical orders are created as test documents, including an order with a voucher, one with several tax rates and one with a refund. Your accounting 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 Lexware 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 Lexware 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 Lexware, the number of special cases with tax rates, payment methods and credit notes 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 Lexware 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 Lexware 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 Lexware 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.