Direct answer: a B2B portal can automate credit checks, the application of payment terms, exposure reservations, payment status and invoice downloads. It should not automate an increase in credit, the removal of a hold or a risk-increasing exception without control. The ERP or finance platform remains the authoritative source; the portal presents and applies a traceable version of its decision.
A sound buyer experience is not achieved by displaying “available credit” as a decorative balance. Before confirming an order, the portal must know which account will be invoiced, which documents consume the limit, how much exposure is being reserved and what happens if the value changes while the buyer completes checkout.
Separate credit limit, exposure and availability
- Credit limit: the maximum approved risk for the invoice account.
- Exposure: amounts already consuming that limit: open invoices and, depending on policy, confirmed orders, delivered but uninvoiced goods and temporary reservations.
- Available credit: the limit minus exposure and authorised adjustments.
- Credit hold: an additional decision that can prevent ordering even when availability remains, for example because of overdue debt or a risk review.
The calculation looks simple, but its scope must be explicit. If the limit is EUR 100,000, open invoices total EUR 55,000, uninvoiced orders total EUR 12,000 and a reservation is EUR 8,000, availability is EUR 25,000 only when all four components use the same currency, account and valuation time. Do not aggregate currencies without an approved exchange rate and effective date.
Resolve the invoice account first
The person placing an order is not necessarily the debtor. A subsidiary may buy while the parent company receives the invoice; several locations may share one limit, or each may have separate terms. The evaluation key should contain at least:
- the buyer’s identity and active company location;
- ordering account and invoice account;
- the seller’s legal entity;
- market and the currency used for credit control;
- evaluation timestamp and version.
Microsoft Dynamics 365 documents how a B2B order can be invoiced to the organisation and use its credit limit instead of an individual user’s limit. This separation prevents risk from being assessed against the wrong party.
What the portal should display
If policy allows customers to see credit information, show the available amount, currency, timestamp and scope: “Estimated availability for ACME Iberia: EUR 25,000, updated at 10:42.” Explain that it will be revalidated when the order is submitted. Do not expose the total limit, invoices belonging to another division or internal risk reasons to unauthorised users.
Do not present stale information as current. Use explicit states such as current, temporarily unavailable or awaiting validation. An old number styled as definitive is worse than a clear message that the value cannot yet be confirmed.
Prevent the same availability from being spent twice
Two buyers from the same company can submit orders concurrently. Reading EUR 25,000 and accepting two EUR 20,000 orders creates EUR 40,000 of exposure. The system governing credit therefore needs an atomic operation:
- calculate current exposure;
- create an identified reservation for the order;
- confirm or reject that reservation;
- convert it into actual exposure when the order is accepted;
- release it if checkout expires or the order is cancelled.
Every reservation needs an amount, currency, account, order reference, creation time, expiry and status. Retrying the same request must be idempotent: a double click or lost response cannot reserve the amount twice.
Payment terms are rules, not free text
“30 days” is ambiguous unless the starting event is defined. Payment terms should specify:
- whether due dates start from order, dispatch, delivery or invoice date;
- calendar days or an agreed payment calendar;
- weekend and public-holiday adjustments;
- deposit percentage and due date;
- early-payment discounts, if applicable;
- permitted payment methods and currency;
- scope: company, location, contract or exceptional order.
Shopify documents company-location terms including payment due on receipt, net 7–90, due dates after fulfilment, fixed dates for specific orders and deposits. The functional lesson is that the selected term and resulting due date belong on the order. A later change to the customer master must not rewrite an existing order.
Keep order, fulfilment, invoice and payment states separate
Do not compress every condition into one “pending” state. At minimum, distinguish:
| Dimension | Example states |
|---|---|
| Order | Draft, confirmed, on hold, cancelled |
| Fulfilment | Not started, partial, complete |
| Invoicing | Not invoiced, partial, invoiced, credited |
| Payment | Not due, partly paid, paid, overdue, disputed |
| Credit | Reserved, approved, rejected, exception pending |
An order can be delivered, partly invoiced and not yet due for payment. Calling all of that “pending” prevents the buyer from taking the right action and makes support unnecessarily difficult.
What to automate and what finance should approve
| Automate through governed rules | Keep under financial control |
|---|---|
| Apply current payment terms | Create or increase a limit |
| Calculate and reserve exposure | Remove an overdue-debt hold |
| Reject against an objective rule | Approve an exceptional excess |
| Release expired reservations | Change the invoice account |
| Publish posted invoices | Issue a credit note without a source document |
| Send due-date reminders | Alter dates already agreed |
An exception record should include requester, reason, amount, approver, validity and exact effect. Avoid a generic “force order” button. The approver should see exposure before and after, overdue debt, the affected account and whether approval applies only to this order.
Invoices, credit notes and downloadable documents
The portal should publish only posted documents or items clearly labelled as pro forma. For each invoice, show its number, issuing legal entity, invoice account, date, due date, currency, original amount, outstanding balance, status and related orders or delivery notes.
A credit note is not an isolated negative invoice: link it to the original document and reason. For partial payments, show the applied amount and remaining balance. Where several legal entities are involved, do not mix numbering sequences or let a user at one subsidiary download another subsidiary’s documents.
PDF files should come from the authorised financial repository or be verified against it. Do not regenerate a fiscal document in the portal with a template that could diverge from the posted original. Log sensitive downloads and enforce permissions by account, location and role.
Synchronisation and latency
Credit and cash allocation change outside the ecommerce platform. Set different service expectations: a reservation needs a synchronous response; an invoice can be published through an event; a bank transfer may appear only after later reconciliation. Every message needs an identifier, version, event time and receipt time.
Process events idempotently and tolerate out-of-order delivery. An old update must not reopen an invoice already marked as paid. If synchronisation fails, retain the last known state with its age, alert operations and decide whether new orders should be blocked or routed for review.
Give the customer an actionable message
Do not show “error 402” or “insufficient credit” without context. State the outcome and an allowed next step: reduce the order, settle overdue invoices, pay immediately, request a review or contact a named team. Never disclose internal scores, risk comments or information from other accounts.
Essential test cases
- An ordering account different from the invoice account.
- Two concurrent orders competing for the same availability.
- A reservation confirmed, expired, cancelled and retried.
- An order just below, exactly at and above the limit.
- Overdue debt while numeric availability remains.
- Net terms, a deposit, immediate payment and an approved exception.
- A partial invoice, credit note, partial payment and dispute.
- An unauthorised user attempting to access another document.
- Duplicate and out-of-order events.
- Amounts, due dates and balances reconciled between portal and ERP.
Frequently asked questions
Must available credit update in real time?
It must be revalidated at confirmation. An earlier estimate can be displayed if its timestamp is clear and it is not represented as a reservation.
Must an order above the limit be rejected?
That depends on policy. It can be held, switched to immediate payment or sent for approval, but it should never be silently accepted.
Can customers change their own payment terms?
Not directly. They can request a review; finance decides and publishes a new version with a defined effective period.
Which documents should a buyer be able to download?
Only documents authorised for that account and role, with fiscal invoices, pro formas, credit notes and receipts clearly distinguished.
Primary sources
- Microsoft Dynamics 365 Commerce: on-account payments and B2B credit limits.
- Microsoft Dynamics 365 Commerce: B2B invoice management.
- Shopify: B2B payment terms and deposits.
- Shopify: B2B companies, locations and customers.
Next step
Select five real accounts and document their invoice account, limit, exposure components, payment terms, invoice permissions and exception route. Then simulate two simultaneous orders and a bank transfer reconciled after a delay. To extend the portal design, explore CODE B2B’s resources.