Deletion Concept Across Shop, ERP and Accounting Systems

The reason lies in the architecture, not in a lack of care. A link between shop and ERP creates copies, that is its purpose. Each copy then sits in a system with its own data storage, its own backups, its own permissions and, this is the decisive point, its own legal basis for storage. The shop stores the customer account because the contract requires it. The ERP stores the same name because it appears on a commercial letter. Accounting stores it a third time because it is part of an accounting document. Three systems, three reasons, three periods.

A deletion concept that does not know these three answers cannot work through them either. It typically fails not because of the technology, but because nobody ever wrote down which copy exists for which reason. The first working step is therefore an inventory of fields, not of systems. How field assignments across system boundaries can be described at all is shown in the article on data mapping between ERP and store; the same list is the basis for every deletion decision.

Shortening the period for accounting documents from ten to eight years comes from the Fourth Bureaucracy Relief Act, promulgated on 29 October 2024 (BGBl. 2024 I No. 323). For deletion concepts, the transitional rule matters more than the figure. Under Art. 97 § 19a (2) EGAO, the new version applies for the first time to all records whose retention period had not yet expired under the law in force up to and including 31 December 2024. The shortening therefore reaches into the existing archive: documents filed under the old ten-year rule whose period was still running may be removed two years earlier.

An archive that still clears after ten years keeps two annual sets longer than required, and under the storage limitation principle that is not a neutral state. For part of the economy, however, the shortening does not apply: Art. 97 § 19a (3) EGAO exempts three groups of taxpayers, and commercial law expressly continues ten years (§ 257 (4) HGB) for their accounting documents. A shop operator supplying such a house is not affected; anyone who belongs to one of these groups documents the deletion class for accounting documents differently. The three groups are named in the law:

A deletion concept that assesses every data type individually is hard to maintain past the third interface. It becomes workable through deletion classes: a manageable number of rules, each bundling a period, a period start, a legal basis and a leading system. Every table, every field and every file in the group is assigned to exactly one class. The benefit shows at the next system change: a new connection inherits classes instead of triggering another round of assessment. In a group made up of shop, ERP and accounting, a small set of classes typically covers most of the data.

The class belongs in a machine-readable file rather than in a presentation, because a checking run is meant to read it later. A workable set contains, per class, a stable identifier, the period in years, the anchor for the start of the period, the legal basis in plain words and the system that calculates expiry. Where the period follows from purpose limitation rather than from a statute, an event takes the place of the number of years: end of contract, withdrawal, last contact. The middleware is the natural home for this file because it already knows every system involved.

Between deleting and keeping sits a third state that many systems handle technically and organisations overlook: the restriction of processing. It is first of all a right of the data subject (Art. 18(1) GDPR). German federal data protection law additionally makes it a substitute for erasure where, in the case of non-automated processing, erasure would only be possible with disproportionate effort and the interest of the data subject in erasure is to be regarded as low (§ 35 (1) BDSG), and under § 35 (3) BDSG also where retention periods under an organisation’s own articles or under a contract stand in the way of erasure. For the group of systems this means the record stays in place but is blocked for every use outside retention.

Technically this is a flag on the record, not a separate folder. A dedicated archive client or an export into a second database only shifts the problem, because the same periods and the same access rules apply there. What works is a restriction flag that the connected processes actually evaluate: marketing selection, recommendation logic, reporting, export lists, the shop search index. If the flag only shows up on an ERP screen, it is decoration.

The stress test for a deletion concept is a data subject request, because it comes with a deadline. The controller provides information on the action taken without undue delay and in any event within one month (Art. 12(3) GDPR) of receipt of the request. That period may be extended by a further two months (Art. 12(3) GDPR) where necessary, taking into account the complexity and number of the requests, and the data subject has to be informed of the extension within the first month. One month sounds generous as long as the answer comes from a single system. Across three systems, half of it regularly goes on working out who looks where.

The way out is the same as for deletion: one case, one route, acknowledgements from every system. What works in practice is an information run that uses the same message path and returns a structured answer per system, covering records found, assigned deletion class, calculated expiry date and restriction status. That answer produces both the information for the data subject and the internal evidence. If customer data also sits in a CRM, it belongs on the same path; which fields arise there is shown in the article on CRM integration with the shop.

The build can be put into a sequence that avoids bringing the project to a standstill. It starts with an inventory and ends with a repeatable run, and at no point does it touch ongoing sales. Experience suggests the second step is the most demanding, because that is where the business assignment happens; technical steps three and four are comparatively straightforward once the classes are in place. Which services interlock along the way is summarised in the overview of services.

The timing of the fourth step is rarely arbitrary. Since almost all periods start at the end of the calendar year, the first live run sensibly falls into the weeks after the turn of the year, the same phase in which stock is being reconciled anyway; how that phase can be planned across the interfaces is described in the article on stocktaking and year-end. For accounting, the same principle applies as for the document transfer itself: DATEV integration determines which documents reach the tax adviser at all, and the formats needed for that are described in the article on DATEV automation in e-commerce. Anyone also moving to e-invoicing should bring the deletion classes along; the article on the invoicing obligation from 2027 sets out the dates.