B2B ecommerce trade credit: how to connect checkout with ERP, limits and invoices

"Pay later" in B2B is not a convenient version of card payment. It is a credit and operations decision. A buyer can have a PLN 150,000 limit, Net 30 terms, open invoices, partial payments, orders in fulfilment, manual finance blocks, different limits per branch and special rules for specific categories.

If the storefront only sees the current cart, it makes the wrong decision. It can block a buyer who paid an invoice in the morning but the ERP balance has not synchronized yet. It can also accept an order even though the buyer already has three open orders and will exceed the limit once they ship.

Good B2B trade credit does not query ERP on every click and does not blindly trust cache. It builds an exposure layer: limit, utilization, reservations, holds, orders, adjustments, payments and invoice statuses. Only that layer should tell checkout whether to continue, require approval, reduce the cart or route the buyer to sales.

Trade credit is the ability to place an order now and pay later based on an agreed limit and payment term, for example Net 14, Net 30 or Net 60. In a B2B store it appears as a payment method, but its logic belongs to finance, risk and ERP.

The key difference from consumer BNPL: B2B is usually not about a one-off consumer installment. It is a commercial relationship with contract limits, invoices, company accounts, branches, order approval and accounting reconciliation. It must be auditable.

In practice, the storefront should answer one question: "how much real available limit does this buyer have now, for this cart, this branch and this delivery date?". If the answer is "we do not know", automation is mostly theatre.

ERP is the system of truth for receivables, invoices, payments and finance blocks. It is not always a good system for checkout traffic. Older SAP, Comarch, Microsoft Dynamics, enova, Subiekt or custom ERP deployments can have API limits, slow reports and posting windows.

The useful ERP data includes customer account, credit limit, payment terms, overdue amount, open invoices, unapplied payments, credit memo, manual blocks, branch hierarchy and invoice status. The store should not ask ERP for all of that on every mini-cart open.

A safer model is event sync plus scheduled refresh: payment posted, invoice issued, credit note, order shipped, order cancelled, limit changed, customer blocked. Checkout uses a fresh projection, and high-value carts can trigger an additional verification before final submit.

Credit limit should not be checked only when the buyer clicks "place order". In B2B, a buyer can work on a cart for several days, and multiple employees from the same company can create parallel carts. Without reservation, two orders can look valid separately and exceed exposure together.

A good build separates soft hold and hard hold. A soft hold can reserve limit for an active cart for a short time. A hard hold is created after order submit and lasts until cancellation, rejection, invoicing or shipment. Every hold needs expiration, owner, source and relationship to the order.

This is where idempotency keys and backend transactions matter. If the buyer double-clicks, the API must not reserve the limit twice. If ERP responds late, the system must know whether the order is accepted, pending approval, blocked or needs finance review.

The Medusa Cart Module provides cart management, addresses, line items, shipping methods, adjustments, tax lines and cart scoping to sales channel, region and customer. The Payment Module handles authorize, capture, refund, payment collections, payment providers and webhook events. That is a strong foundation, but trade credit needs custom domain rules.

At GMI we usually do not put exposure rules inside React components. Next.js shows limit status and checkout path. MedusaJS keeps the commerce core. NestJS or a domain module handles credit policy, exposure ledger, ERP adapters, approval workflow, idempotency, retry policy and audit log.

This split helps later with mobile commerce. React Native/Expo can use the same endpoints: `getAvailableCredit`, `reserveCredit`, `releaseHold`, `submitForApproval`, `confirmInvoicePayment`. You do not build a second credit engine for the mobile app.

Trade credit does not end when the order is accepted. After checkout comes the cycle: order accepted, shipment, invoice issued, payment due, reminder, partial payment, credit note, dispute, overdue block and reconciliation. Each state can change available credit.

If you use Stripe Invoicing or a similar invoicing layer, keep payment terms separate from the credit decision. An invoice can have `collection_method=send_invoice`, payment due date and credit notes, but the commerce system still needs to know whether the buyer may place another order before paying the previous one.

Reconciliation should compare at least four sources: storefront order, exposure ledger, ERP accounts receivable and payment/invoicing provider. Without this, finance exports CSV files and manually explains why the store showed PLN 40,000 available while ERP blocked the account.

The worst UX is "credit limit exceeded, contact sales". A B2B buyer needs operational information: available limit, used exposure, overdue invoices, missing amount, partial payment option, approval flow or account-manager contact with cart context.

A strong checkout shows three paths: the order fits the limit and continues, the order requires approval, or the order needs payment change or cart reduction. Larger accounts also need PO number, cost center, buyer role, branch selection and downloadable documents.

This matters especially on mobile. If the React Native app shows a simplified message without invoices and limit context, the buyer will still call sales. Automation merely moved the problem from checkout to support.

In DDT we start with finance, sales, operations and IT in the room. We map customer types, limits, payment terms, blocks, invoices, credit notes, returns, approval, ERP API, posting windows, integration SLA and failure scenarios. Without finance at the table, trade credit only looks easy in mockups.

A typical stack is MedusaJS as headless commerce core, Next.js storefront, NestJS for exposure ledger and integrations, PostgreSQL for transactional records, Redis/queues for sync and retry, ERP/PIM/WMS and a payment/invoicing provider. If mobile is an ordering channel, we add React Native/Expo on the same API contracts.

After DDT we can discuss fixed price because the risks are known: ERP data quality, API availability, credit-policy rules, approval flow, reconciliation, observability, account migration and handover. The client keeps source code, documentation and architecture without vendor lock-in.

Use this list before choosing a platform or integrator. Without these answers, the project may work in the happy path and fail at the first partial payment, overnight posting window or invoice dispute.

• Which system is the truth for credit limit, overdue invoices, open orders and manual blocks?
• Is the limit per company, branch, buyer role, currency, region or sales channel?
• When do we reserve limit: cart, submit order, approval, shipment or invoice?
• How do we release holds on cancellation, partial shipment, return or credit note?
• How do we handle partial payment, credit note, dispute, overdue block and sales override?
• How often do we sync ERP, and what happens when ERP is unavailable?
• Which statuses do we show buyers instead of a plain "limit exceeded"?
• How does reconciliation compare storefront, exposure ledger, ERP and invoicing provider?