A trade customer places an online order on account. The website confirms it, the warehouse starts preparing it, and finance then discovers the customer should have been on hold. The problem is not necessarily the agreed payment term. It may be that the website never checked the current account position before making a fulfilment commitment.
For Australian and New Zealand wholesalers, distributors and trade retailers, online account ordering connects customer experience with back-office controls. Buyers need a convenient way to order, while sales, finance and operations need a consistent answer about whether an order can proceed.
Credit limits, overdue balances, payment terms and manual account holds describe different conditions. Copying a payment-term label from the ERP does not establish that all those conditions will be enforced through checkout, order creation and dispatch.
This guide explains how to scope that connection, compare implementation options and test the difficult cases. The business’s authorised finance team remains responsible for credit policy and individual account decisions; the implementation should apply those approved rules consistently.
Key Takeaways
- Separate when payment is due from whether an account is permitted to place or fulfil another order.
- Define one authoritative account decision and make its relationship with the storefront explicit.
- Include open orders, concurrent purchases, payments, cancellations and stale data in acceptance testing.
- Give buyers and staff clear order states, review ownership and recovery paths.
Separate payment terms from permission to proceed
Payment terms describe when payment becomes due. A credit limit sets an approved boundary for account exposure under the business’s policy. An overdue condition concerns amounts past their due date. A manual hold may prevent further activity even when the balance is below the limit. These conditions should not be collapsed into one ‘approved customer’ flag.
Shopify’s B2B payment-terms documentation, for example, describes due dates and company-location terms. It also explains that payment is not automatically captured when terms expire. Those functions need to be distinguished from the retailer’s ERP credit checks, collection process and account-hold rules.
Start with an agreed vocabulary shared by finance, sales, eCommerce and fulfilment. Define whether a hold prevents creating an order, releasing it, shipping it or only using account payment. The answer may differ by condition, but it must be explicit enough to configure and test.
The following table is an implementation checklist, not a recommended credit policy. Have the people authorised to set that policy specify the actual rules and permitted exceptions.
| Condition | Decision to document | Evidence the systems need |
|---|---|---|
| Payment term | When is this order due? | Approved term and its date basis |
| Credit availability | Can this purchase proceed on account? | Limit, exposure definition and current commitments |
| Overdue position | Does an overdue balance trigger review or restriction? | Relevant ageing status and approved rule |
| Manual hold | Which actions are restricted? | Hold scope, reason category and current status |
| Exception approval | Who can release which order? | Authorised reviewer, decision, scope and audit trail |
Choose the source of the account decision
Where finance already manages customer balances, limits and holds in the ERP, assess how that decision can remain authoritative for online orders. If another approved system owns the decision, map that responsibility instead. Avoid letting multiple systems independently maintain conflicting versions of the same account status.
Document the debtor or account identifier, company structure, branch relationships and any relevant currencies. The person signing in, the delivery address and the legal purchasing account are not necessarily interchangeable. A buyer moving between locations should not accidentally obtain a separate credit allowance unless that is the intended account model.
The integration should return enough information to apply the agreed action, not necessarily every financial detail. A storefront might need a decision, reason category, timestamp and permitted next step. Which balances or limits the buyer can see is a separate permissions decision.
Our guide to connecting B2B pricing with contracts and the ERP examines a similar ownership problem for prices. Credit controls need their own mapping and acceptance criteria, even if they use the same connector.
Define exposure before displaying available credit
A balance field is useful only when everyone understands what it includes. Ask finance and the ERP team how the approved exposure calculation treats unpaid invoices, open sales orders, dispatched but uninvoiced goods, deposits and unallocated receipts. Do not design a second calculation in the storefront merely because the source fields are easy to obtain.
For an illustrative example, suppose the approved rule starts with a NZD 10,000 limit, NZD 6,000 in unpaid invoices and NZD 2,500 in other committed orders. It would leave NZD 1,500 before considering a new purchase. Looking only at unpaid invoices would suggest NZD 4,000 and could produce a different decision. These figures describe a fictional rule, not an ERP default or an OSE customer.
Agree how tax, freight, rounding and later order edits affect the amount being assessed. Specify how cancellations and partial fulfilments change commitments, and when payments become eligible to restore availability. The right events depend on the approved operating model and the deployed systems.
For businesses trading across Australia and New Zealand, document the account currency and conversion responsibility. An AUD order and an NZD credit figure cannot be compared without a defined method. Include the entity and account scope so separate storefronts do not imply separate allowances unintentionally.
Choose where the authoritative check happens
There are several implementation patterns. A synchronised storefront can use a locally stored account status for browsing and early guidance. A live check can ask the authoritative system for a decision during submission. Another approach records the order for review and waits for a back-office decision before fulfilment. Each needs clear boundaries.
Synchronised data can make the journey responsive, but its age matters. A status copied before an account was placed on hold may no longer support a new commitment. Specify acceptable freshness, how updates are monitored and what happens when that freshness cannot be established.
A live check introduces its own dependency: the decision service must respond and the subsequent order must be associated with the decision. A positive response followed by an unrelated order submission is not automatically a protected transaction. Establish whether the source supports reservation, commitment or revalidation, and what those operations mean.
If review is the chosen boundary, make it real. The order should have a state that prevents downstream fulfilment until the authorised action occurs. Define what the customer is told and who owns the queue. A website confirmation must not promise dispatch while another system is still deciding whether the order can proceed.
Handle simultaneous orders across branches and channels
Two buyers can submit orders while looking at the same available amount. Sales staff may also enter a telephone order, and another branch may sell on the same debtor account. Checking each request against an unchanged snapshot does not establish that the combined commitments fit the approved limit.
Discuss this explicitly with the ERP and integration teams. Determine where commitments are recorded, whether the source serialises or reserves them, and how the final order is linked to its check. If the source cannot provide that protection, document a controlled review or release boundary rather than claiming real-time checks solve every concurrency problem.
Order retries create a related risk. A submission may time out after the source has recorded a commitment. Retrying it as a new purchase can duplicate the order or reserve exposure twice. The AWS Builders’ Library explains why retries need idempotent operations. Use stable transaction identifiers and a lookup or reconciliation process appropriate to the systems involved.
Acceptance testing should include concurrent purchases and delayed responses, not just a single buyer proceeding through checkout. Our article on ERP integration failure recovery explains why recovery must follow the actual business action, rather than only the success or failure of an API request.
Check platform capability against the required control
Adobe Commerce provides company credit with Payment on Account for its B2B implementation. Its company-credit documentation describes credit currency, limits, outstanding activity and a setting that allows a company to exceed its limit. Verify that setting and the installed configuration when testing enforcement.
That native ledger still needs a defined relationship with back-office transactions. Adobe’s CompanyCredit integration overview describes reimbursement adjustments, while its credit-management API reference distinguishes the allocated limit from calculated available credit. Decide which events and identifiers keep the commerce and ERP views aligned.
For Shopify, demonstrate the proposed account-control workflow separately from the availability of payment terms. Specify which native configuration, application, integration or custom work performs the check and which system prevents release. Our Shopify B2B plan guide for NZ retailers explains why plan entitlements and an end-to-end implementation are different questions.
ERP controls are also configuration-dependent. Microsoft’s current Dynamics 365 Finance credit-hold guidance describes blocking rules, checkpoints and exclusions. Do not assume a field labelled credit limit blocks every electronically submitted order, or use instructions for a different credit-management mode without checking the deployed version.
Give buyers a clear next step without exposing account information
When an account order cannot proceed automatically, explain the result at the right level for that buyer. A useful message can say the order needs account-team review, preserve the basket and provide a contact route. Avoid exposing detailed debt, internal risk notes or another branch’s financial position to a user who is not authorised to see it.
Distinguish a policy decision from a technical failure. ‘Your account needs review’ and ‘We cannot confirm account availability right now’ describe different conditions. The second should not imply the customer has failed a credit check when the actual problem is an unavailable integration.
Agree which alternatives are allowed. Finance may approve a review path or an alternative payment method for some conditions, but a manual account hold may have a broader purpose. The implementation should not silently bypass that hold by presenting a different payment option.
Make order status understandable after submission too. Explain whether the order is awaiting review, approved for processing or already released. Customer-service staff should see enough context to help without inventing an answer or repeatedly submitting the same order.
Treat release, payment and cancellation as controlled events
An order review needs an owner, not just a status label. Document who can approve an exception, which order or amount it covers, how long it remains valid and what evidence is recorded. An order-specific exception should not accidentally become a permanent change to the customer’s credit settings.
Decide what happens when an approved order changes. Increasing its value, changing the purchasing account or editing payment terms may require another check under the business’s rules. Define this before staff start editing orders across the ERP and commerce administration screens.
Payment notifications, credit notes and cancellations also need agreed meanings. A notification that money was initiated is not necessarily the finance event your policy uses to restore availability. Identify the approved source event and handle duplicate, delayed and out-of-order messages without applying the same adjustment twice.
Microsoft’s credit-management parameter guidance illustrates that rechecking released orders is configurable. Test your actual release and posting sequence. A deliberate exception and an unintended bypass can look similar unless the system records who approved what and why.
Test a complete account lifecycle before rollout
Create a compact test set with finance, sales and warehouse reviewers. Include an account within its limit, a purchase that exceeds availability, an overdue account and a manual hold below the limit. Record the expected action for each case before testing, including whether the order can be created, released and fulfilled.
Add the difficult transitions: two simultaneous orders, a payment followed by another purchase, an order cancellation, a partial fulfilment, an edited order and a hold applied while a buyer is already in checkout. Include a connector outage and the recovery of a submission whose final state is initially unknown.
Compare the storefront message, order state, ERP commitment and fulfilment permission after each test. Checking the page alone is insufficient. Verify that dashboards and support tools can identify the order and explain any discrepancy without relying on a developer to read raw logs.
Pilot with a defined customer group and an agreed escalation process. Measure inappropriate releases, unnecessary reviews, unresolved state mismatches and staff handling effort. Changes in online sales or payment performance need separate evidence; implementing a gate does not prove a commercial improvement by itself.
Scope the investment around decisions and ownership
A useful project brief names the authoritative system, account relationships, exposure definition, check points, order states and recovery responsibilities. Ask prospective partners to demonstrate the mandatory scenarios and identify where the proposed connector or platform needs additional work.
Compare the full operating cost of each approach: implementation, connector or application subscriptions, monitoring, support, manual review effort and future rule changes. A low-cost status synchronisation may be appropriate for early guidance while still requiring a separate authoritative release control. Make that boundary visible in the scope.
OSE’s approach is to connect the buyer journey with the systems that approve and fulfil the transaction. Talk to OSE about reviewing your B2B account-ordering workflow if checkout terms, ERP holds and warehouse actions currently give different answers. Bring representative orders and approved rules so the assessment can focus on the controls your business actually needs.
Frequently asked questions
No. Payment terms describe when an order is due. A credit limit concerns approved account exposure, while overdue conditions and manual holds may create additional restrictions. Specify each rule and its effect on order creation, release and fulfilment separately.
Use the system authorised by the business to make the account decision. Where finance already manages it in the ERP, assess how online ordering can follow that source. Define account mappings, update events and permitted storefront information rather than maintaining competing calculations.
Not on its own. Two requests can receive decisions based on the same unchanged position. Establish how commitments are reserved or recorded, how orders link to checks and where final release is controlled. Test concurrent orders and retries explicitly.
Both provide relevant B2B capabilities, but the required enforcement must be demonstrated in the deployed implementation. Adobe Commerce has company credit with Payment on Account. Shopify payment terms should be assessed separately from ERP holds and any additional account-control application or integration.
Follow an agreed fallback rather than silently treating the account as approved. Depending on approved policy, preserve the basket, queue a clearly labelled order for review or offer an authorised alternative. Explain the technical interruption without implying the customer has failed a credit assessment.