Credit control in B2B

In B2B you deliver first and get paid later. That single fact creates a whole layer of control that a consumer shop never needs, and it is the layer that decides whether an order is accepted.

You are lending your customers money

A consumer shop takes the money before the parcel leaves. Card, PayPal, direct debit: the transaction is settled before there is any risk. If the payment fails, nothing ships.

B2B does not work like that, for a practical reason. A workshop that orders forty times a month does not want forty payment transactions and forty receipts. They want goods on account, one invoice, and terms. So you ship, you invoice, and for the next 30 or 60 days that customer owes you money.

That is trade credit, and it means every B2B seller runs a small lending business alongside the commerce one. Three fields control it.

The three levers

All three sit on the organization, never on a person. The receivable is the company's; whose login placed the order does not change who is invoiced.

Payment terms

payment_terms is a code from a list you maintain yourself; nobody types a number of days into the record. A store ships with prepayment, direct_debit, net_7, net_14, net_30, net_60 and net_90, and you can add or retire entries.

An empty value means nothing has been agreed, and downstream that is an answer in its own right: a company with no agreed terms is one you have not extended credit to. A store default fills the field for companies created without one, so decide the default deliberately.

Terms are also the mechanism behind the classic German B2B expectation: Rechnungskauf, buying on account, which many buyers treat as the minimum bar for a supplier being usable at all. If your shop only offers prepayment, expect to hear about it.

Credit limits

A credit limit is a ceiling on open receivables: the total of what has been delivered and invoiced but not yet paid. People describe it as a limit per order or as a monthly spend cap. It is neither.

Credit limits need a number nobody in the shop has. The open-item balance lives in the ERP or the accounting system, and that is where the limit is enforced. What the commerce platform carries is the agreed figure, so it can be shown, exported, and used in the decision.

Empty means no limit. A store-wide default can be applied to companies created without one.

Delivery blocks

delivery_block is a boolean, and it is more useful than it looks because of what it does not do:

• The company can still sign in.
• The company can still browse and see its prices.
• The company can still place an order.
• Nothing ships.

That is the correct instrument for the ordinary case: an invoice went past due, somebody in accounts is chasing it, and you do not want to shut the customer out over what is probably a payment run that has not landed. The order is captured, the goods are reserved, the block comes off, the shipment goes.

Compare it with status: blocked, the heavy instrument: the company may not trade at all. Reaching for blocked when you meant delivery_block is how a good customer discovers on a Monday morning that their login stopped working.

The risk decision, in order

A working credit process makes these decisions in this sequence. Write yours down in the same shape:

1. Before the first order. Who is this company? Is the VAT ID real? This is the point at which a self-registration should be approved or refused, not after they have ordered. See Self-registration.
2. At the start of the relationship. What terms and what limit? A new customer on prepayment for the first few orders is normal, and no insult.
3. On each order. Does this order plus what is already open exceed the limit?
4. When something goes wrong. Delivery block first. Blocked status only if the relationship is over.
5. Periodically. A limit set three years ago for a company that now orders ten times as much is a limit that blocks good business.

How this works in the Revenue Cloud

All four commercial fields (payment_terms, credit_limit, price_list and delivery_block) are real columns on the organization, edited together on the Commercial terms panel of the organization's page in CRM › Organizations. They are columns rather than entries in a settings blob precisely because other apps have to agree with you about them.

Three details to know:

• price_list is a code, not a link. It names the price list the company buys on. The list itself belongs to the Pricing app. See Price lists.
• The credit limit is denominated in the market's currency and the platform does not convert it. A company trading in two currencies needs that thought through rather than assumed.
• The organizations list filters on all of it. The list carries counters for active companies and for companies with a delivery block, and filters for status, lifecycle stage, payment terms and delivery block. "Who is currently blocked" takes two seconds instead of a report.

What the platform does not do is compute your open-item balance. Enforcing a credit limit against real receivables means the ERP tells the platform, or the platform hands the order to the ERP for the decision. Decide which, and see Deciding your system of record.

Next

• Set payment terms and a credit limit — the actual task.
• Block a customer — which of the three blocks to use.