Distributors talk about net terms as an accounts receivable problem. It mostly is not. The hard part is a half second at the end of checkout, when a buyer on terms hits submit and something has to decide whether that order goes through.

That decision used to belong to a person. Once buyers can order without a rep in the loop, it belongs to a rule, and most distributors discover they never wrote one down.

The pressure behind this is real. Atradius, in its September 2025 Payment Practices Barometer for North America, found that 43 percent of credit-based B2B sales in the US are overdue, and that 5 percent of long overdue invoices get written off as uncollectable. Those are the numbers that make an operator nervous about letting orders through unattended.

What does net terms at B2B checkout actually mean?#

Net terms at checkout means the buyer submits an order against an open account instead of paying at that moment. The checkout is not processing a payment. It is making a credit decision.

That decision reduces to available credit, which is the credit limit minus current exposure. Every design argument you will have about terms ordering is really an argument about what belongs in exposure.

Get the definition right and the rest is mechanical. Get it wrong and you either strand good customers or discover the problem in your aging report sixty days later.

Why does the phone hide the credit decision?#

On a phone order, an inside sales rep is the credit check. Someone glances at an aging report, remembers that this account has been slow lately, and either takes the order or says they will call back.

That works, in the narrow sense that it produces a decision. It also means the rule lives in one person's head, applied unevenly, with no record of why an order was held.

Self-serve removes that person from the loop. This is the moment most distributors find out they did not have a credit policy, they had an employee. Writing the rule down is usually the actual blocker on a self-serve rollout, not the catalog and not the integration.

It is worth naming plainly: ordering by phone, fax, or email does not remove the credit decision. It hides it.

What counts as available credit at the moment of submit?#

The naive answer is open invoices. Limit minus what is currently invoiced and unpaid. This is the most common mistake in the category.

It fails because an order exists before an invoice does. A buyer can submit five orders in one morning, none of them invoiced yet, and clear the full limit five separate times. Every check passes. Nothing is wrong until everything is.

Exposure has to include approved orders that have not been invoiced yet. Work an example with round numbers:

Credit limit: 25,000
Open invoices: 18,000
Approved order not yet shipped or invoiced: 4,000

Available credit is 3,000, not 7,000. The 4,000 order is a commitment you have already accepted. Treating it as invisible until the paperwork catches up is how a limit gets cleared twice.

The symmetry matters just as much in the other direction. If approved but uninvoiced orders count against a buyer, then issued credit memos should count for them, and should reduce exposure the moment they are issued rather than when the back office applies them against specific invoices. A buyer who returned 3,000 of goods on Tuesday should be able to reorder on Tuesday. Application still matters for AR truth. It should not gate whether the buyer can transact.

That is the whole rule: exposure recognizes commitments in both directions, at the moment they are made.

Warn or deny: what should the store do when the answer is no?#

There are two defensible behaviors, and choosing between them is a business call rather than a technical one.

Warn. The order still submits and is flagged for a human to look at. This is right for long standing accounts where a stopped order costs you more than the credit risk does. Your rep sees the flag, makes a judgment, and the order keeps moving in the meantime.

Deny. The order is refused at submit, with the numbers shown. This is right for new accounts, thin margins, and any relationship where you would rather have the conversation before the goods leave than after.

Most distributors want both, applied per customer tier. A twelve year account and an account that opened in March should not get the same treatment, and a single global setting forces you to pick the wrong answer for one of them.

One rule gets missed constantly and is worth stating on its own. A credit limit of zero, or a limit that was never set, means not configured. It does not mean no credit. If your enforcement logic treats an unconfigured account as an account with no available credit, you will block your oldest and largest customers on day one of the rollout, because those are exactly the accounts nobody ever bothered to enter a number for. Unconfigured accounts pass through. Full stop.

Whatever the store does, it has to show the buyer the actual figures: the limit, the current exposure, and the shortfall. A vague failure at submit sends a buyer straight back to the phone, which is the outcome the entire project exists to prevent.

How does credit work for multi location buyers?#

A buyer with four branches is either one credit relationship or four, and you have to decide which. Both answers are legitimate and they behave very differently.

Independent limits per location are simple to reason about. Each branch has its own ceiling and its own exposure. The tradeoff is that the parent has no ceiling at all, because four branches at 25,000 each is a 100,000 relationship nobody approved.

A shared pool puts the parent limit over the whole tree. This is what most industrial buyers actually expect, especially where purchasing is coordinated centrally and the branches are cost centers rather than businesses.

Pooled credit has one edge case worth naming before you build it. Two branches submitting at the same moment can both pass a check against a limit that only one order fits under. Each request reads the pool, sees room, and approves. The fix is that a pooled check has to serialize submissions against the pool rather than letting them evaluate in parallel. It is a small detail that only shows up under real concurrency, which means it shows up in production rather than in testing.

What should the buyer see before checkout?#

Most credit friction is a visibility problem wearing a policy costume. The buyer is not trying to exceed a limit. They do not know where the limit is.

Put the answers in the account, not at the moment of submit:

Open balance and available credit, visible before they build a cart, not discovered when it fails.
The invoice list with aging, so a buyer who is blocked can go clear the blocker themselves. Plenty of overdue invoices are sitting in an approver's inbox on the buyer's side, and a distributor holding an order has no way to say so unless the store shows it.
The terms on the account stated plainly, so nobody on either side is guessing whether this account is Net 30 or Net 60.

The pattern behind all three is the same one that makes self-serve work anywhere: give the buyer enough information to solve their own problem, and they will, at two in the morning, without calling anyone.

A checklist before you turn terms ordering on#

Four decisions, all of which need an owner rather than a default:

Write the exposure definition down and have finance sign it. Specifically, whether approved uninvoiced orders count, and when credit memos take effect.
Decide warn or deny per customer tier, not once globally.
Handle the unconfigured limit case explicitly, and confirm those accounts pass rather than fail.
Decide pooled or independent credit for every parent account before the first multi location buyer signs on, because migrating it later means renegotiating with a customer.

None of this requires new software. It requires answering four questions that a phone-based operation never had to answer out loud.

Where this fits#

If you sell on Shopify, the terms themselves are already handled. Shopify B2B gives every paid plan companies, payment terms from Net 7 to Net 90, and PO numbers at B2B checkout. What it does not give you is the decision this whole piece is about. Shopify's payment terms will mark an invoice overdue, but they do not hold an order against a credit limit, and they do not auto-capture at expiry. There is no credit limit, no exposure calculation, and no warn-or-deny at submit on any Shopify plan. The credit call still happens in somebody's head, or in a spreadsheet, or after the truck has left.

That gap is what Copiara's credit and AR layer is for: a limit per company, shared or independent across branches, live exposure that counts approved but uninvoiced orders rather than just open invoices, and a warn or deny at the moment of submit. Quoting, approvals, and credit sit in one flow rather than three systems that reconcile weekly, and payment state is read back from Shopify rather than kept as a second version of the truth.

Copiara is not on the Shopify App Store yet, which is the honest status. If you are working through a terms ordering rollout and want to compare notes on where these decisions land, talk to us.

Net Terms at B2B Checkout: The Credit Call in a Second