In B2B trade, few buyers pay in advance. Purchase on account is by far the most popular payment method: 95 percent of B2B buyers want to order on invoice in the online shop, yet only 45 percent of merchants offer this option (bevh). Anyone offering it effectively grants every business customer a supplier credit -- and carries a default risk. That risk is real in 2026: the number of company insolvencies reached its highest level in over ten years in 2025 with around 23,900 cases, up 8.3 percent on the previous year (Creditreform), and in March 2026 the filed proceedings were 15.8 percent above the same month a year earlier (Destatis). A credit-limit check directly in the checkout reconciles credit limit, open items and payment terms in real time from the ERP before the order is confirmed -- and decides whether purchase on account is approved, capped or blocked. This article shows how the payment integration to SAP, Dynamics or DATEV works technically and how to embed the default risk into the order process.
Key takeaways
- The credit-limit check verifies in real time, before order confirmation, whether a business customer's credit limit, open items and payment terms support the order.
- The data source is the ERP or financial accounting: SAP, Microsoft Dynamics or DATEV provide credit limit, balance and overdue items via an interface.
- The result steers the checkout: approval of purchase on account, partial approval with a deposit, or a switch to prepayment when the limit is exceeded.
- If the ERP fails, a defined fallback strategy prevents the shop from either approving blindly or blocking across the board.
- The check processes economic and personal data and belongs on a sound data-protection basis.
Why the Credit-Limit Check Becomes Liquidity Protection in 2026
A defaulted purchase on account hits the supplier twice: the goods are gone, the money does not arrive. For 2025, Creditreform estimates the damage from company insolvencies at around 57 billion euro, with an average defaulted claim of over 2 million euro per insolvency case (Creditreform). The Federal Statistical Office registered 24,064 filed company insolvencies for the full year 2025, up 10.3 percent (Destatis), and in the first quarter of 2026 the number of proceedings was 6.5 percent above the same quarter a year earlier (Destatis). Small firms are hit especially hard: 81.6 percent of all company insolvencies in 2025 concerned businesses with up to ten employees (Creditreform) -- exactly the customer group that often orders on invoice in the B2B shop.
Payment behaviour also pushes the risk further out. The average payment term granted in German B2B business rose to 32.13 days in the second half of 2025, the highest value in more than seven years (Creditreform). While the delay after the due date fell to 7.50 days (Creditreform), every day between delivery and payment is a day of credit risk. A late-paid invoice had an average value of 1,838 euro (Creditreform) -- added up across many open items, a substantial amount quickly builds that is at risk in the event of insolvency. Our article on payment reconciliation in the ERP match shows how incoming payments are later matched cleanly against open items.
The checkout is the last line of control
Supplier credit included
Every purchase on account is a short-term credit to the customer. Without a limit check, the open exposure grows uncontrolled.
Long payment terms
Payment terms of 30 days and more extend the span during which a receivable is open and therefore at risk.
Many small orders
Regular customers order several times a month. Only the sum of all open items shows whether the limit still holds.
Distributed data ownership
The credit limit lives in the ERP, the order in the shop. Without an interface, the checkout does not know the current balance.
Stale states
Nightly exports lag behind reality. Between two runs, a customer may have long exhausted their limit.
Manual approval too late
A back-office check after the order arrives slows the delivery and only bites once the order is already placed.
What the Checkout Checks: Credit Limit, Open Items, Payment Terms
A credit-limit check is more than a yes-or-no switch. It evaluates several figures from the ERP together and derives a decision from them. The overview below shows which values feed in, where they come from and how they act in the checkout.
| Figure | Source | Effect in the checkout |
|---|---|---|
| Credit limit | ERP debtor master | Upper bound of the permitted open exposure |
| Open item balance | Debtor account | Reduces the available headroom |
| Overdue items | Open-item list | Trigger a warning or a block |
| Payment terms | Payment conditions | Steer deadlines and discount |
| Blocking flag | Debtor master | Blocks purchase on account immediately |
| Credit or risk class | ERP or credit report | Tightens or loosens the rule |
The central calculation is the available headroom: credit limit minus the balance of open items minus the value of the current cart. In the example of the diagram, a credit limit of 50,000 euro faces open items of 28,500 euro -- so the available headroom is 21,500 euro. An order of 9,200 euro fits within it; after posting, the limit is about 75 percent utilized and purchase on account is approved. If the cart exceeded the available headroom, the checkout would switch to prepayment or offer a partial payment. Overdue items feed in as well: if invoices are already open beyond the permitted overdue threshold, purchase on account is blocked even when the nominal limit still holds on paper.
For the amount in the checkout to be correct, the customer-specific prices must also be right -- the checked cart value decides on approval or block. How to bring customer-specific prices and tiers from the ERP cleanly into the shop is therefore closely linked to the credit-limit check. The actual check logic belongs in a central middleware so that it applies uniformly across all sales channels and is maintained in one place when rules change.
The Real-Time Data Flow from Checkout to ERP
The core of the solution is a fast, traceable data flow between checkout and ERP. It begins as soon as the customer selects invoice as the payment method and ends with a decision that the shop implements immediately. In between lie a few clearly delimited steps.
- Cart snapshot: The checkout determines the customer (debtor), the cart value and the chosen payment method.
- Credit query: A request to the interface fetches credit limit, balance and overdue items from the ERP.
- Rule evaluation: The middleware calculates the available headroom and applies the approval rules.
- Decision back: The checkout receives approval, partial approval or a block including the reason.
- Logging: Request, response and decision are recorded in an audit-proof way.
Response time is decisive. The check sits on the critical path of the purchase, so it must not slow the checkout noticeably. In practice this means a lean API integration with a clear time limit, direct queries instead of heavyweight exports, and a short-lived cache for repeated queries of the same customer. Our article on SAP-Shopware real-time synchronization explores how shop and ERP are coupled technically in real time. The approval rule itself can be expressed compactly:
def evaluate_credit(customer, cart, erp):
data = erp.credit_snapshot(customer.debtor_id)
# data: credit_limit, open_balance, overdue, blocked
if data.blocked or data.overdue > OVERDUE_LIMIT:
return Decision("prepayment", reason="blocked_or_overdue")
available = data.credit_limit - data.open_balance
if cart.total <= available:
return Decision("invoice", reason="within_limit")
if cart.total <= available + TOLERANCE:
deposit = cart.total - available
return Decision("partial", reason="near_limit", deposit=deposit)
return Decision("prepayment", reason="limit_exceeded")Steering Order Release, Blocking and Purchase on Account
The result of the check is not a plain yes or no but a graduated set of decisions. Each level has a fitting reaction in the checkout that limits the default risk without needlessly rejecting converting orders.
| Situation | Decision | Customer experience |
|---|---|---|
| Cart within headroom, no overdue items | Purchase on account approved | Order as usual |
| Cart slightly above headroom | Partial approval with deposit or reduced quantity | Alternative instead of abort |
| Limit exceeded or blocking flag | Switch to prepayment or card | Order possible, without credit risk |
| Overdue items above threshold | Purchase on account blocked, note to clarify | Protection against further exposure |
Blocking does not mean losing
Which payment methods are offered in the block case is configured in the payment integration. When orders arrive not through the shop checkout but through a customer's procurement portal, the same rules apply -- the check then moves to the order handover point. How to connect such processes is described in our article on OCI punchout integration of procurement portals.
Connecting to SAP, Dynamics and DATEV
Where the credit data lives depends on the leading system. In SAP, the classic credit management or SAP Credit Management holds the credit limit per debtor; balance and open items can be queried via standardized interfaces. In Microsoft Dynamics 365, credit limit and payment terms sit in the debtor master and are reachable via the Business Central or Finance interfaces. In the DATEV world, it is primarily the open items and the debtor master that are available -- an explicit credit limit is often maintained in the middleware or shop and combined with the open items from DATEV.
SAP
Credit limit in classic credit management or SAP Credit Management, balance and open items per debtor via standardized interfaces.
Microsoft Dynamics 365
Credit limit and payment terms in the debtor master, retrievable via the Business Central or Finance interfaces.
DATEV
Open items and debtor master as the basis; the credit limit is maintained additionally in the middleware and combined with the DATEV data.
For the check to be reliable, the debtor master must be maintained consistently -- one customer number, one limit, one balance, no duplicates. How to synchronize master data for this cleanly is deepened in our article on master data synchronization with MDM. Only on this basis does the credit-limit check deliver dependable decisions instead of false alarms from inconsistent customer assignments.
Performance, Resilience and Data Protection
A credit check in the checkout is only as good as its availability. Because it sits on the critical path of the purchase, it needs defined behaviour for the case that the ERP is slow or unreachable. The following measures keep the checkout stable without losing sight of the risk.
- Time limit with defined behaviour: If the ERP does not respond within a few hundred milliseconds, a pre-defined fallback rule applies instead of a hang.
- Conservative fallback: With no response, purchase on account is deferred rather than approved blindly -- this guards against wrong decisions.
- Short-lived cache: A limit snapshot valid for a few minutes absorbs load spikes without risking stale states.
- Idempotent queries: Repeated checks of the same order must not create contradictory decisions or double postings.
- Complete logging: Every decision is traceable with a timestamp, the input data and the rule reference.
The check moves sensitive data -- credit limit, payment history, and with external reports also credit-scoring attributes. This processing needs a sound legal basis, data minimization and a documented purpose limitation; only what is needed for the approval decision is queried. Because the interface between shop and ERP is a sensitive route, it belongs technically secured. How to harden ERP interfaces against unauthorized access and what the NIS2 directive requires is described in our article on NIS2-compliant protection of ERP interfaces. The guide on error handling in interfaces additionally shows how exceptions are caught in a controlled way instead of failing silently.
No blind approval on system failure
Project Sequence of a Credit-Limit Integration
About half of companies already automate their business processes with digital technologies (Bitkom) -- the credit-limit check is a concrete, well-delimited building block of that. Implementation typically follows five phases, with close coordination with accounting and credit management deciding the quality of the rules.
Five phases to a productive credit-limit check
- 1
Assessment
Capture the leading system (SAP, Dynamics or DATEV), any existing credit management, the offered payment methods and special cases such as bulk orderers.
- 2
Define the rule set
Set approval thresholds, tolerances, the handling of overdue items and the fallback together with accounting and credit management.
- 3
Build the interface
Develop the connector to the ERP, the check logic in the middleware and the return of the decision to the checkout.
- 4
Test run with real data
Check historical orders against the rules, calibrate the thresholds and measure the response times under load.
- 5
Go-live and monitoring
Productive operation with monitoring of approval rate, blocks and response times, followed by continuous fine-tuning.
Common Pitfalls and How to Avoid Them
Integration projects reveal recurring mistakes. Anyone who plans for them from the start saves expensive rework and avoids wrong decisions in live operation.
- Nightly export instead of real time: Limits exhausted between two runs stay undetected until it is too late.
- Only limit, no overdue check: A limit kept while invoices are long overdue is deceptive -- the overdue check belongs with it.
- Cart not included: Anyone checking only the standing balance overlooks the value of the current order.
- Hard block without alternative: An abort without a replacement payment method costs the revenue that a prepayment option would have saved.
- No fallback on ERP failure: Blind approval or blanket blocking are both expensive -- the fallback rule must be defined.
- Data protection treated as secondary: Processing credit data without a legal basis and purpose limitation is an avoidable risk.
A credit-limit check is not distrust of the customer, but the condition for offering the convenient purchase on account broadly and durably in the first place.
Sources and studies