Custom Payment Terms for B2B Accounts

Payments + Shipping & Fulfilment
,
1

Hi is there any way to customise the default list of payment terms? Specifically, trying to set payment terms for [company] in B2B accounts, but seem to be limited to the default set of:

  • no payment terms
  • due on fulfllment
  • net 7
  • net 15
  • net 30
  • net 45
  • net 60
  • net 90

Would like to be able to add:

  • Net 14
  • EOM+30
  • EOM+45
  • EOM+60

but cannot find where to edit this list, or if it could even handle the EOM logic…

2

Hi @pixiiau :waving_hand: the paymentTermsTemplates api, and UI, don’t have ways to set custom terms in general.

So it’s a matter of either starting with no terms, on fulfillment, or an existing NET-X template…
THEN editing the order to set the proper terms at some point in the process (paymentTermsCreate or paymentTermsUpdate.
I’ve set up this up before using the mechanic app, might be possible in the free flow app as well.
Reach out if you need that process.

Optionally configure each company’s checkout -setting to be “Submit all orders as drafts for review”, see embedd screen below.

The annoying part can be stepping through the entire buyer journey to find any and all friction in the buyer experience caused by just auto displaying what’s set in shopify with no way to override the text; vs what the final outcome is supposed to be.
At minimum you’ll want notification templates to be updated for some custom easy to configure logic.
And make it clear in any TOS/contract that the contracts wording take precedence over any such text discrepancy in what text for payment-terms

buton to edit a companies checkout-settings to auto submit orders as draft orders in the b2b company LOCATION shopify admin
buton to edit a companies checkout-settings to auto submit orders as draft orders in the b2b company LOCATION shopify admin630×249 4.74 KB

3

Hey @pixiiau Paul’s right that the default B2B dropdown is locked to those built-in options.

Worth knowing there’s a second path at a different layer: apps built on Shopify’s checkout customization can apply payment terms at the moment of checkout, independent of the company-level dropdown. That’s where the logic you’re asking about becomes possible.

Applied to your list:

  • EOM+30 / +45 / +60: Shopify has no native EOM type, so the calculation has to happen somewhere. A checkout-level app can compute end-of-month + N on the spot and apply it as the due date. Works dynamically per buyer, per company, per order size. One thing to know: the buyer sees the resolved date (“Due May 30, 2026”) on their confirmation, not the literal string “EOM+30”. If the “EOM+30” label matters for your finance or invoice records, Paul’s after-the-order rename is the clean complement, the two stack cleanly.

  • Net 14: Shopify’s built-in Net templates are locked to 7/15/30/45/60/90, so Net 14 isn’t available as a Net template anywhere. But a checkout-level app can apply it as a specific due date 14 days out and the behavior is identical. Same display caveat, buyer sees the resolved date, not “Net 14” as a label.

  • Per-company / per-tag / per-order-size routing: this is what a rules engine handles, so you stop managing terms per company in the dropdown and start managing them as rules that match whatever buyer/order shape you want.

I build TermStack (Plus-only) for exactly this, a rules engine that runs at checkout. You define rules like “company = Acme → Net 30” or “order total ≥ $10k and customer tag = wholesale-net45 → Net 45, 20% deposit.”
Conditions available: company, company location, customer tag, order total, collections in cart, first-time buyer, prior order count. Outcomes include the standard Net terms, due-on-fulfillment, due-on-invoice, and no terms, each with an optional deposit.
Simulator to test before publishing, version history with rollback, immutable audit trail.

EOM and Net 14 via custom due dates are both on the near-term build list. If you’re ready to use them, DM me, I can prioritize both and get you on early access as we roll them out. Biased because I build it.

4

Good breakdown. I’d add one finance-side distinction here: custom payment terms solve when the buyer pays, but they don’t solve how much credit exposure the merchant is willing to accept.

For example, Net 30 is fine until a buyer with $25k already outstanding places another $12k order. Native terms can let the order through, but finance may not want that risk.

That’s where a checkout validation layer makes sense: keep Shopify’s native payment terms, but block or warn when the company exceeds its approved credit limit.

Disclosure: I’m building TermShield specifically for that credit-limit enforcement layer.