On 6 February 2026, the amendment to the German Foreign Trade and Payments Act (Außenwirtschaftsgesetz, AWG) entered into force, transposing Directive (EU) 2024/1226 of 24 April 2024 into German law (Foreign Trade and Payments Act, Federal Law Gazette). For every B2B store shipping abroad, this shifts the risk position in three places at once: under section 18(8a) AWG, even reckless conduct is now a criminal offence once the act concerns dual-use items listed in Annex I or Annex IV of Regulation (EU) 2021/821 -- punishable by up to three years imprisonment or a fine (Foreign Trade and Payments Act, Federal Law Gazette). The maximum corporate fine has risen from 10 to 40 million euros (Foreign Trade and Payments Act, Federal Law Gazette). And the former grace period, which ran until the end of the second working day after a sanctions act was published in the Official Journal, has been removed without replacement (Foreign Trade and Payments Act, Federal Law Gazette). A prohibition on making funds available has no de minimis threshold anyway -- it applies to the order that passes through self-service checkout at 11 p.m. as well. This article shows the four points where screening has to take effect technically, how the check enters the order process as a service call without damaging conversion, and why the chain of store, middleware and ERP is an interface project.
What the AWG Amendment Has Shifted Since February 2026
The amendment implements Directive (EU) 2024/1226, which sets EU-wide minimum rules for the criminal prosecution of sanctions violations. The legislator did not merely fine-tune but restructured section 18 AWG. Newly covered are violations of financial sector prohibitions, of sectoral transaction bans such as rental and leasing contracts, and of investment prohibitions (Foreign Trade and Payments Act, Federal Law Gazette). For particularly serious cases, section 18(6a) AWG provides a penalty range of six months to ten years (Foreign Trade and Payments Act, Federal Law Gazette). The basic offence under section 18(1) AWG remains at three months to five years imprisonment (Foreign Trade and Payments Act, Federal Law Gazette). This is no longer a niche concern of the export desk but a question of management liability.
Three changes hit store operations directly. First, section 18(8a) AWG lowers the subjective threshold: anyone who recklessly violates certain prohibitions and licensing requirements commits a criminal offence as soon as dual-use items from Annex I or Annex IV of Regulation (EU) 2021/821 are involved -- up to three years imprisonment or a fine (Foreign Trade and Payments Act, Federal Law Gazette). Intent does not have to be proven; gross carelessness in the process is enough. Second, the maximum fine against legal persons under section 19(7) and (8) AWG has risen to 40 million euros (Foreign Trade and Payments Act, Federal Law Gazette); alongside this, administrative offences under section 19(6) AWG remain punishable by up to 500,000 euros (Foreign Trade and Payments Act, Federal Law Gazette). Third, the former section 18(11) AWG has been deleted. It acted as a ground for exemption from punishment where the act was committed before the end of the second working day after publication in the Official Journal and the person acting had no knowledge of the prohibition (Foreign Trade and Payments Act, Federal Law Gazette). That grace period is gone.
| Item | Before the amendment | Since 6 February 2026 |
|---|---|---|
| Recklessness with dual-use items from Annex I or IV | not covered by section 18(8a) AWG | criminal offence: up to 3 years imprisonment or a fine |
| Maximum corporate fine (section 19(7) and (8) AWG) | 10 million euros | 40 million euros |
| Grace period after publication in the Official Journal | until end of the second working day | removed without replacement |
| Particularly serious cases (section 18(6a) AWG) | narrower scope | 6 months to 10 years imprisonment |
| Reporting frozen funds (section 18(5a) AWG) | not penalised in this form | incorrect, incomplete or late reporting is punishable |
| Practical consequence for the store | a daily list refresh was mostly defensible | new entries take effect on publication |
Removing the Grace Period Hits Automated Processes First
The Prohibition on Making Funds Available Has No De Minimis Threshold
Regulations (EC) No 2580/2001 and (EC) No 881/2002 prohibit making funds or economic resources available to listed persons, groups and organisations. What matters is the scope of that prohibition: it applies regardless of the amount and has no threshold below which a delivery would be harmless (Regulation (EC) No 881/2002). Goods are an economic resource. So the box of sealing rings for 38 euros falls under the same prohibition as the six-figure machine delivery. Anyone who ties their rulebook to order values builds in a gap that opens precisely where nobody is looking.
The volume of law to be observed is considerable. By its own account, the European Commission has more than 40 different sanctions regimes in force at the same time -- geographical regimes against individual countries and thematic regimes covering, for instance, terrorism, human rights violations and cyber attacks (European Commission). The consolidated list of persons and organisations subject to EU financial sanctions is maintained continuously by the Commission and reflects the legal acts published in the Official Journal (European Commission). BAFA states the consequence for companies unambiguously: all natural and legal persons who receive resources -- customers, forwarders, employees -- must be screened, and depending on the extent of business contacts, screening software should be used (BAFA).
The Store Is the Channel Without Four-Eyes Review
Four Points Where Screening Must Take Effect
Export control asks four questions: to whom are you delivering, where, what exactly, and for what purpose. Companies must check for themselves whether their exports are affected by one or more of these measures (IHK München). The store is not a screening system here but the channel in which the answers to the first two questions arise and change. That is why a single check at checkout is not enough. Four points in the process create or alter data relevant to screening -- and the check has to attach to each of them.
Business customer registration
During business customer onboarding, company name, legal form, address and contact persons come into existence. This is the first moment at which a person can be screened at all -- and the cheapest, because no order is yet at stake.
Change of billing and delivery address
A customer who was clean at registration can later change their delivery address to a third country. If screening happens only at account creation, the follow-up order runs unchecked into a country that played no part during onboarding.
Checkout
Here the orderer, the cart, the delivery address and any differing consignee condense into a concrete transaction. Checkout is the last point at which the store itself can hold the transaction before a commitment arises.
Order release in the ERP
The ERP owns the transaction and decides on shipment. This is where the final documented release belongs -- including a repeat check if time has passed between screening and dispatch.
The fourth point has a hard justification. BAFA requires that if the period between completion of the export control check -- usually with the printing of shipping documents -- and delivery of the goods exceeds five working days, a renewed check of all parties involved is mandatory, and it recommends implementing a corresponding check routine in export control workflows (BAFA). In B2B this is the rule, not the exception: drop shipments, backorders, consolidated deliveries and call-off dates blow past the five-day mark easily. Screening that happens only at checkout does not meet this requirement when lead times run to three weeks.
The Parties Involved Are More Than the Orderer
The Check as a Service Call in the Order Process
The obvious but wrong solution is to copy the sanctions list into the store. It changes continuously, it is spread across several legal acts, it contains name variants and transliterations, and it has to be verifiable by version. A store is the wrong system for that job. The workable path is a service call: the store hands the screening data to a service that checks against the consolidated EU list and returns a result with a timestamp and list version. The store knows only the result, not the list. For Shopware in its open-source variant this means concretely: the screening status is held on the customer and the order, while the domain logic stays outside.
Technically, middleware belongs between store and screening service. It decouples the two systems, holds the screening status, retries failed calls and logs every transaction. How such an interface architecture for B2B stores is built comes down to the same questions as any integration: idempotency, timeouts, retry logic and defined behaviour when the service does not respond. The last point is the most important and the most frequently overlooked. A screening service that fails must neither let everything through nor block everything -- it has to move the transaction into a defined waiting state.
- Define the triggers: registration, address change, checkout and order release call the check, not a nightly batch run.
- Normalise the screening data: bring company name, legal form, address, natural persons and differing consignees into a uniform format.
- Call the service: the service checks against the consolidated EU list and returns result, list version and timestamp.
- Process the result: no match proceeds, unclear cases go to status pending, matches land in manual release.
- Catch failures: on timeout or error the transaction is held and queued for review instead of passing through silently.
- Log it: every call is stored in an audit-proof record with input data, list version, result and decision-maker.
Screening Without Damaging Conversion
The legitimate objection from sales is that screening which blocks checkout costs revenue. The objection is right, but the conclusion usually drawn from it is wrong. The alternative to a hard block is not skipping the check but handling the result differently. A transaction being screened does not have to wait synchronously in checkout. It can be accepted and given the status pending -- the order is captured, the customer has a confirmation, but release for shipment has not yet been granted. In B2B this is the normal case anyway: credit checks, availability and picking sit between order receipt and dispatch.
Hard Block Versus Asynchronous Screening with a Status
Synchronous block in checkout
Checkout waits for the screening service to answer and aborts on any ambiguity. Simple in theory, expensive in operation.
- Every bit of latency in the service lengthens checkout
- An outage of the service brings the order process to a halt
- Name similarities cause abandonments for clean customers
- The customer gets a rejection without a comprehensible reason
Asynchronous screening with status pending
The order is accepted, release for shipment follows the check. The transaction stays stoppable.
- Checkout stays fast and independent of the screening service
- The transaction is captured and can be stopped before dispatch
- Unclear cases go to humans, not to an error page
- Goods are made available only after a documented release
The second lever is the quality of the name match. Sanctions lists contain name variants, spellings from non-Latin alphabets and inconsistent transliterations, which is why an exact character comparison comes up empty. Fuzzy matching solves this but produces false positives. BAFA offers a practical anchor here: a percentage setting of not below 80 percent has proven itself in practice, and it is advisable to link the name components to be checked with an AND function so that only records are shown where both first and last name match (BAFA). This reduces the number of time-consuming manual reviews in which, for example, only the first name appears on the lists (BAFA).
The third lever is how a match is handled. A match is not a verdict but a suspicion. Automatic rejection produces exactly what nobody wants: lost orders on name coincidence and a customer who does not understand why their account is blocked. BAFA therefore requires written procedural rules that specify in detail how matches are verified and how probable matches are to be handled -- for example, reporting to the competent authority once a match has been found (BAFA). And for listed goods: stop and release functions must be installed in the system to prevent unintended dispatch, and releases may only be granted by authorised and trained personnel (BAFA). That is precisely a four-eyes release, not an auto-reject -- technically the same pattern that sits behind approval workflows for budgets and sign-offs, just with a different rationale.
A hit on a sanctions list is a reason for a human to look, not a reason to reject automatically. The machine holds the transaction; export control makes the decision.
Control List Classification and Customs Codes from ERP and PIM
Screening people is only one of four dimensions. The goods-related check asks what is being delivered -- and in the store that is considerably more demanding, because it hangs on the article. Every article needs its classification: the entry in the export control list or in Annex I of the Dual-Use Regulation, the customs tariff number, and the information on whether a licence is required. This data does not originate in the store. It lives in the ERP or the PIM and has to travel from there to the article -- as a maintained field, not as free text in the product description.
With bought-in goods it gets uncomfortable. BAFA is explicit: a classification made by the seller or manufacturer is helpful but not sufficient -- a plausibility check of that classification is necessary, and it is not sufficient to rely on the information provided by manufacturers or suppliers when classifying goods (BAFA). On the system side: classification should be supported by an electronic data processing system, and changes to the control list must be entered into the system without delay (BAFA). On top of that comes an obligation that reaches straight into the documents: listed dual-use items may only be shipped within the EU if the business documents contain a reference to the classification of the goods (Dual-Use Regulation (EU) 2021/821, Article 11(9)). So the store must not only know this information but pass it through to order confirmation and delivery note.
- Classification as a dedicated, maintained article field instead of free text
- Define the leading system: ERP or PIM, not both at once
- Keep the customs tariff number and the control list entry separate
- Plausibility check of bought-in classifications as a process step
- Transfer control list changes into the leading system without delay
- Pass the classification reference through to the business documents
Data Quality Is the Quiet Prerequisite
Audit-Proof Logging: No Evidence Means No Check
From an authority's point of view, a check that is not documented did not happen. BAFA phrases the requirement identically in two places: the check should be documented in a suitable manner and attached to the export transaction -- both for screening against sanctions lists and for reviewing embargo rules (BAFA). The individual check steps are to be documented precisely at all stages of handling a project, and documentation should also take place when the export control office concludes that no application to BAFA is required; in particular, the reasons leading to that conclusion are to be recorded (BAFA). So the negative result carries the same logging duty as the hit.
For retention, section 22(3) AWV and Article 27 of the Dual-Use Regulation apply; beyond that, BAFA recommends keeping the relevant documents for at least ten years (BAFA). The records must be capable of being made accessible to the competent authorities, and it should be possible to provide them electronically (BAFA). For system architecture, one clear requirement follows: the screening log does not belong in a log file that rotates after 30 days but in an immutable record attached to the transaction. It must be reconstructable which list version was checked against, and with which threshold -- years later, after the list has changed twenty times.
- Timestamp and trigger: when was the check run, and which process step triggered the call?
- List version: which version of the consolidated list was used for the comparison?
- Data checked: which parties and fields went into the comparison, including differing consignees?
- Parameters: which matching threshold and which linking logic were configured?
- Result: no match, unclear or match -- with the similarity score of the comparison.
- Decision: who assessed a match, and on what grounds was it released or held?
Where Screening Belongs in Functional Terms
A clean separation saves a lot of argument in the project. The leading system for export control is the ERP, not the store. That is where orders, deliveries, documents and the release live. The store is the triggering channel: it creates the data relevant to screening, calls the check and holds the transaction until a decision exists. This division also matches organisational reality. Under the German government's reliability principles, depending on legal form, a member of the management board, a managing director or a partner authorised to represent the company must be appointed as the person responsible for exports (Ausfuhrverantwortlicher) (BAFA). Responsibility sits with the management, not in the store back end.
| Task | B2B store | ERP and compliance service |
|---|---|---|
| Capture data relevant to screening | creates it in self-service | takes it over from the channel |
| Hold the sanctions list | holds no list | checks against the consolidated EU list |
| Trigger the check | at four defined points | additionally checks before dispatch |
| Assess a match | shows only a neutral status | four-eyes release by trained personnel |
| Maintain goods classification | displays and passes the field through | owns and updates the classification |
| Keep the log | logs the call on the transaction | holds the audit-proof evidence |
Two Systems, One Document Chain
GDPR: Matching Personal Data Against Lists
The check processes personal data and therefore needs a legal basis. For matching against EU sanctions lists, processing rests on the respective statutory rules in conjunction with Article 6(1)(c) GDPR -- compliance with a legal obligation (General Data Protection Regulation). For matching against lists of states outside the EU and EEA, that direct obligation is missing; here the legitimate interest under Article 6(1)(f) GDPR regularly comes into play, which requires a documented balancing of interests (General Data Protection Regulation). This distinction is not a formality: it decides whether a match is permissible across the board or has to be justified.
On top of that come the duties every processing operation brings. Data subjects must be informed about the processing under Articles 13 and 14 GDPR -- so the check belongs in the privacy policy and in the information given at registration, not in an internal procedural note (General Data Protection Regulation). The principle of data minimisation under Article 5 GDPR requires handing over only the fields necessary for the comparison (General Data Protection Regulation). And deletion creates a genuine conflict of goals: the screening log should be available for at least ten years per BAFA's recommendation (BAFA), while data minimisation and storage limitation pull in the other direction. This is resolved through a justified retention rule, not through quietly keeping everything.
- Document the legal basis per list: EU lists via Article 6(1)(c), third-country lists via point (f) with a balancing test.
- Extend the record of processing activities: enter purpose, categories, recipients and retention periods of the check.
- Inform data subjects: the check belongs transparently in the privacy notice and the registration flow.
- Limit the fields: hand only the data necessary for the name comparison to the screening service.
- Regulate processing on behalf: if an external screening service is used, a contract under Article 28 GDPR is required.
- Justify retention: derive the period for screening logs from the foreign trade law obligations and record it.
Not a Data Protection Project on the Side
Store, Middleware and ERP as an Interface Project
That completes the picture -- and it shows why the task is not a plugin click. The chain has four links: the store creates the data and calls the check at four points. The middleware decouples, retries and logs. The compliance service matches against the consolidated list. The ERP owns the transaction, manages the goods classification and carries the documented release. Each link has its own responsibility, and the handovers in between are the actual work. That is the definition of an integration project -- and exactly the scope we deliver as integrations and interfaces.
BAFA frames the task with nine criteria for an internal compliance programme: management commitment, risk assessment, organisational structure, human and technical resources, process organisation, record-keeping and retention, personnel selection and training, process- and system-related checks, and physical and technical security (BAFA). For internal reviews, the rule is: ideally once a year and at least every three years (BAFA). A software project covers only part of that -- the part that does not work without clean interfaces. Anyone building the chain should neither talk the effort down nor inflate it: it is plannable once responsibilities are clarified up front. Fittingly, the work can be bundled with tasks that are due anyway, such as a maintenance and upgrade strategy for Shopware 6.7.
Assessment
Which countries are supplied, which articles are classified, where does the classification live today, and at which points does the store create data relevant to screening?
Process design
Triggers, status model, failure behaviour and match handling as a four-eyes release -- written down before the first line of code is created.
Evidence and acceptance
Log fields, retention and the question of how the check can be reconstructed for an authority years later -- part of acceptance, not of rework.
The Entry Point Is the Data, Not the Software
Sources and Studies