What is a credit limit, in the order money actually moves?
Buying on account is the default in B2B. The customer places an order, you ship it, you invoice it, and they pay you 30 days later. The A credit limit is the amount a customer may owe at any one time. Buying on account, often on thirty-day terms, is standard in B2B and the limit is enforced by the ERP. is the cap on how much they are allowed to owe you at any moment, and it is your finance team’s main control over how much of your business is exposed to one customer.
Five numbers combine into the one that matters, and they update at different times. The credit limit is set by your credit manager and changes rarely. The open accounts receivable balance is the total of invoices raised and not yet paid, and it moves whenever you invoice or receive a payment. Unshipped orders are the value of orders taken and not yet invoiced, which is exposure your finance team can see but your invoice ledger cannot. Days past due is how overdue the oldest unpaid invoice is. Available credit is what is left after all of that.
Two of those five are why this is hard on a storefront. Available credit changes several times a day in a working business, and it depends on unshipped orders that only the ERP knows about. A number cached last night is not a credit position, it is a memory of one.
The other thing to understand before evaluating platforms: a credit limit is not one rule. Most ERPs check several conditions and can put a document on hold for any of them. Acumatica, for example, checks the credit limit and separately checks days past due, so a customer well inside their limit can still be stopped for an overdue invoice. If your storefront only models the limit, it will approve orders your ERP is going to stop.
Checked against: Acumatica help: credit verification rules, implementation activity
What do Shopify B2B and BigCommerce B2B Edition actually enforce?
These are two different answers and the difference should change your shortlist. Both were checked against vendor documentation on 20 August 2026.
Shopify B2B has payment terms and no credit limit. Shopify documents four payment term templates: no payment terms, net periods of 7, 15, 30, 45, 60 or 90 days, due on fulfilment, and a fixed date that is available on draft orders only. It also documents that "Payments aren’t automatically captured when the payment terms expire", and that an order past its term displays as Overdue. Nothing in Shopify’s payment terms documentation or in its overview of B2B features describes a credit limit, an outstanding balance, or a rule that blocks a cart when a company owes too much. Deposits and partial payments exist and are both restricted to the Shopify Plus plan.
BigCommerce B2B Edition does model credit, and the fields are specific. Its company credit configuration exposes creditEnabled, creditCurrency, availableCredit, limitPurchases and creditHold. BigCommerce documents the enforcement plainly: "When limitPurchases is TRUE, the PO payment method will be disabled for any orders exceeding availableCredit", and "When creditHold is TRUE, no transactions except invoice payments will be allowed for any of the company’s users." Payment terms are held separately as a number of days, defaulting to the store’s terms when a company has none of its own.
Read the BigCommerce documentation carefully before you rely on it, because there is a caveat that changes what the feature means. The available credit figure is evaluated per order, and existing orders and open invoices do not reduce the availableCredit value shown. So a company with a $50,000 available credit figure and $48,000 of unpaid invoices can place another $50,000 order, and BigCommerce will allow it, because each order is measured against the same static number. Something has to keep availableCredit current, and that something is your integration.
| Criterion | Shopify B2B | BigCommerce B2B Edition |
|---|---|---|
| Payment terms | Templates for no terms, net 7, 15, 30, 45, 60 and 90, due on fulfilment, and fixed date on draft orders only. | A numeric payment terms value in days per company, falling back to the store default when the company has none. |
| Credit limit field | None documented. Not in the payment terms documentation and not in the overview of B2B features. | Yes: availableCredit, with creditEnabled, creditCurrency, limitPurchases and creditHold alongside it. |
| Enforcement at checkout | None on credit. Terms decide when payment is due, not whether the order is allowed. | The purchase order payment method is disabled for orders exceeding availableCredit when limitPurchases is true. |
| Does the platform track what is already owed?This is the row that decides how much integration work the credit story needs, on either platform. | No. Orders past their terms show as Overdue, and payments are not captured automatically when terms expire. | Not by itself. BigCommerce states existing orders and open invoices do not reduce the availableCredit value shown. |
| Hard stop for a bad debtor | No native equivalent. The nearest lever is setting the company location to checkout to draft so orders arrive for review. | Yes: creditHold blocks all transactions except invoice payments for every user on the company. |
Checked against: Shopify Help Centre: B2B payment terms, read 20 August 2026, Shopify Help Centre: overview of B2B features, read 20 August 2026, BigCommerce docs: B2B credit and payment terms, read 20 August 2026
Where does the ERP fit, and what does Acumatica actually do?
The live credit position lives in the ERP because that is where invoices, receipts and unshipped orders live. No commerce platform holds those, and none of them should.
Acumatica runs credit verification when a document is saved, and it can put a sales order or an invoice on credit hold. The checks are separate rules rather than one: the credit limit is one, days past due is another. A user with the right rights can release a held document, which is the mechanism your credit manager already uses on phone orders.
Acumatica’s Shopify B2B connector datasheet, dated 23 September 2025, describes both halves of the integration story. It lists mapping Shopify payment terms to Acumatica credit terms, so the terms a buyer sees at checkout can come from the ERP. And it describes credit monitoring to "Reduce online risk with credit monitoring capability and place risky orders on hold", which is the hold landing in Acumatica after the order arrives rather than at the storefront before it is placed.
That is the shape to internalize. On the Shopify path, the credit decision happens after checkout, in the ERP, where a person then has to release it or phone the customer. Whether that is acceptable is a business question, not a technical one, and the answer depends on how often your customers actually breach their limits. Ask your credit manager how many orders went on hold last month. If it is two, you do not have a storefront problem. If it is 80, you do.
Checked against: Acumatica Shopify B2B Connector datasheet, dated 23 September 2025, Acumatica help: credit verification rules
What are your four options when the storefront cannot read the live position?
Every B2B build lands on one of these four, and the choice belongs to your finance team rather than to your developers. The failure mode to avoid is choosing by accident, which is what happens when nobody asks the question and the platform default wins.
| Criterion | How it works | What the buyer experiences | What it costs you |
|---|---|---|---|
| 1. Let it through, hold it in the ERP | The storefront accepts every order on terms. The ERP runs credit verification and puts the order on hold. | A confirmation email, then a phone call from your credit team a day later. The order does not ship. | Nothing to build, and it is the Shopify default. The cost is trust: a buyer who is told after the fact stops believing the confirmation email, and your credit team inherits a queue. |
| 2. Push a snapshot of available credit nightly | A scheduled job writes the ERP figure onto the customer record on the storefront, as a metafield or a company credit field. | They see a number that is right most of the time and wrong after a big shipment. | Cheap and honest if you label it as of last night. Dangerous if you present it as live, because a stale number that blocks a good order costs you a sale you never hear about. |
| 3. Call the ERP at checkout | The storefront asks the ERP for the live position when the buyer chooses terms as a payment method. | A truthful answer, including being told at checkout that they need to pay by card today. | Development plus an ERP dependency at the worst possible moment. You need a written rule for what happens when the ERP does not answer, and "block the order" is rarely the right one. |
| 4. Take terms off the storefront entirely | Online orders are card or prepay only. Anything on account goes through a rep, EDI or a quote. | Consistent, if less convenient. Nobody is ever told no after the fact. | You have scoped the problem out rather than solved it, and you may suppress online adoption among exactly the accounts you most want online. Reasonable as a first release, weak as a destination. |
What should the buyer actually see?
This is the part that gets skipped, and it is the part your customers will judge you on. A credit control that is invisible until it fires reads as a broken website. A credit control that explains itself reads as a supplier who is organised.
Six things worth putting in front of a signed-in buyer, in rough order of value. None of them require the live-position architecture; the first four work off a nightly snapshot as long as you say so.
One caution on the last item. Showing a buyer their own aged balance changes your collections process as well as your website, because your customers will start correcting your ledger. That is usually good. Tell your accounts receivable team before you turn it on, not after.
Their payment terms, stated on the cart and the confirmation, so nobody has to phone to ask whether this order is net 30.
Their purchase order number field, required if their procurement rules require it. This one field prevents more invoice disputes than any other.
Their credit limit and available credit, with the date it was calculated shown next to it if it is not live.
A clear explanation when terms are not offered as a payment method, rather than the option quietly vanishing.
The status of an order that has been held, visible in their account, so the first they hear of it is not silence.
Their open invoices and what is overdue, which is the single feature B2B buyers ask for most often once a portal exists.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Does Shopify B2B support credit limits?
- No, as of 20 August 2026. Shopify B2B supports payment terms, with templates for net 7 through net 90, due on fulfilment, and a fixed date on draft orders only, but neither Shopify’s payment terms documentation nor its overview of B2B features describes a credit limit or an outstanding balance check. Enforcement on Shopify therefore happens after the order reaches your ERP, or through custom work at checkout. Setting a company location to checkout to draft is the nearest native lever, and it reviews every order rather than only risky ones.
- Does BigCommerce B2B Edition enforce a credit limit at checkout?
- Partly. BigCommerce documents that when limitPurchases is true, the purchase order payment method is disabled for any order exceeding availableCredit, and that a creditHold flag blocks all transactions except invoice payments for the company. The limitation to understand is that BigCommerce evaluates availableCredit per order and states that existing orders and open invoices do not reduce it, so keeping that figure aligned with the real position in your ERP is integration work you own.
- Should the storefront block an order that exceeds a credit limit, or let it through and hold it?
- Ask your credit manager how many orders went on hold last month. If credit holds are rare, letting orders through and holding them in the ERP is cheaper and nobody notices. If holds are routine, blocking at checkout with a clear message is worth building, because the alternative is a queue for your credit team and a stream of confirmation emails your customers learn to distrust. Do not block on a stale number, though: refusing a good order because last night’s snapshot was wrong costs you a sale you will never hear about.
- What happens to a Shopify net 30 order when it reaches the ERP?
- The terms have to be mapped, or the order arrives looking like something it is not. Acumatica’s Shopify B2B connector datasheet dated 23 September 2025 lists mapping Shopify payment terms to Acumatica credit terms, which is the mechanism that keeps a net 30 order out of your cash receipts. Prove this in a sandbox with a real terms order before launch, because an order on terms that imports as paid is a reconciliation problem your finance team will find at month end rather than at go-live.
- Can we show a customer their outstanding invoices on the storefront?
- Yes, and it is consistently one of the most-used features in a B2B portal, but it is an integration rather than a platform feature on every platform Celeste scores. The data lives in your ERP accounts receivable ledger and has to be read out per signed-in company. Decide before you build whether the list is live or refreshed on a schedule, and label it accordingly, because a customer looking at an invoice list is checking your numbers against theirs.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.