B2B payment in Germany: why invoice still wins, and what it costs you
Kauf auf Rechnung is not a nice-to-have in German B2B, it is the default. Here is what it really costs — credit checks, terms, dunning, the ERP handshake — and how a card-only shop quietly loses buyers to email.
Photo: free stock photography (Unsplash licence) — see imprint
In German B2B, invoice is not a payment method — it is the expectation
A purchasing clerk at a mid-sized manufacturer does not have a company credit card. They have a cost centre, an approval limit and an accounts payable department that pays on the 30th. When they land on your shop, find the part they need, and reach the checkout to be offered PayPal and Visa, they do not enter their private card details and claim it back on expenses. They close the tab and send your sales address an email asking for a quote — or they order from the competitor whose checkout understood how their company works.
The loss is invisible, which is why it survives so long. Nobody files a support ticket saying 'your payment options do not fit my procurement process'. You see a normal-looking cart abandonment rate and a sales inbox that is mysteriously full of manual order requests, and you conclude that your customers just prefer the personal touch. They do not. They prefer to be able to buy.
What invoice purchase actually costs
Offering it is not free and anyone who tells you otherwise has never run the receivables. You are extending unsecured credit to a company you have not met, for goods you have already shipped, with the money arriving somewhere between two weeks and never. On a 30-day term, every euro of revenue is a euro of working capital you have lent out. Grow 40% and your financing need grows with it — the fastest-growing B2B shops are the ones most likely to have a cash problem while being profitable on paper.
Then there is the machinery. A credit check at registration or at first order above a threshold. A credit limit per customer that the shop enforces at checkout, not after. Payment terms that may differ per customer, sometimes with an early-payment discount. Dunning: a reminder, a first notice, a second, and eventually a decision about whether this relationship goes to a collections agency. Each of these is a process with a human in it, and none of them exists in a B2C shop.
- Credit check on registration or above an order threshold.
- A credit limit the checkout enforces before the order, not after.
- Per-customer payment terms, sometimes with early-payment discount.
- A dunning sequence somebody actually owns and runs.
- A decision rule for when an account goes to collections.
The credit check is a business decision wearing a technical costume
Everyone wants to talk about which credit agency to integrate. That is the easy part — it is an API call and a score comes back. The hard part is what you do with the score, and that is not an engineering question. What score is good enough for a 500-euro order? For a 15,000-euro one? Does a long-standing customer with a mediocre score get their limit anyway? Who overrides the machine, and does the shop let them?
Projects stall here far more often than on the integration. Get the business rules decided before the sprint, on paper, with the person who owns the receivables in the room. A pragmatic first version that most teams can live with: new customers pay by prepayment or card until their first invoice clears, existing customers get invoice up to a limit derived from their history, and everything above the limit routes to a human. That is a week of work and it covers the overwhelming majority of orders.
The ERP handshake is where the project actually lives
Invoice purchase only works if the shop and the accounting system agree about reality. The shop needs to know the customer's limit and their current open balance to decide at checkout. The ERP needs the order with the right terms, the right customer number and the right tax treatment. When the payment lands, someone or something has to match it to the invoice, release the limit, and stop the dunning clock. If that loop is manual, your invoice option scales exactly as far as one person's Tuesday.
This is the honest reason invoice projects cost more than the estimate. The payment method is a checkbox. The integration — customer master data, limits, open items, payment matching — is the work, and it touches a system that finance owns and is nervous about. Budget for the handshake, not for the checkbox, and expect the slowest part of the project to be a meeting rather than a deployment.
When you should not offer it
There are cases where card-and-prepayment-only is correct, and we would rather say so than sell you an integration. If your average order is small and your customers are one-person businesses, the credit check and dunning overhead can genuinely exceed the margin on the orders it protects. If you have no ERP and no finance function — if invoices are a spreadsheet — then adding unsecured credit to that is not a commerce project, it is a liquidity risk. And if you are one bad quarter from a cash problem, lending your revenue out for 30 days at a time is a decision for your bank, not your web agency.
For everyone else — a real B2B catalogue, real companies buying repeatedly, an ERP that exists — the question is not whether to offer invoice. It is why you have not, and how many quotes your sales inbox is processing this month that a checkout should have handled by itself.
| Method | B2B acceptance | What it costs you |
|---|---|---|
| Invoice (30 days) | Expected as default | Working capital, credit risk, dunning process |
| Prepayment | Accepted for new accounts | Delays shipment; unpopular for repeat orders |
| Direct debit (SEPA) | Good with known customers | Mandate handling, chargeback window |
| Credit card | Limited — many buyers have none | Fees, plus B2B carts silently abandoned |
| PayPal | Rare in procurement | Fees; awkward to reconcile against an ERP |
- A card-only B2B checkout does not lose the order — it converts it into an email.
- On 30-day terms, every euro of growth is a euro of working capital you lend out.
- The credit agency call is easy; deciding what to do with the score is the project.
- Without a working payment-matching loop, invoice scales as far as one person's Tuesday.
Frequently asked questions
If your buyers are companies with a purchasing process, yes — it is the default they expect. Purchasing clerks often have no company card and cannot put an order on a private one. Without invoice they do not abandon loudly; they email your sales address for a quote, which you then process by hand. Look at how many manual orders your inbox handles and you have your answer.
Layer it. New customers pay by prepayment or card until their first invoice clears. Existing customers get invoice up to a limit derived from their payment history. Anything above the limit routes to a person. Add a credit agency check above a value threshold if the order sizes justify it. The rules matter more than the tooling, and they must be agreed with whoever owns receivables before anyone writes code.
The payment method itself is nearly free — it is a checkbox. The cost is the ERP handshake: customer master data, credit limits, open items and matching incoming payments back to invoices so limits release and dunning stops. That integration is the project, and it touches a system finance owns. Budget for the handshake and expect the slowest step to be a meeting, not a deployment.
When small average orders from one-person businesses mean the credit check and dunning overhead exceeds the margin it protects. Or when you have no ERP and no finance function — invoices in a spreadsheet plus unsecured credit is a liquidity risk, not a commerce feature. If your cash position is tight, lending revenue out for 30 days at a time is a conversation with your bank first.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer