How Agencies Scope B2B Payment Terms on Shopify Plus

A Shopify Plus B2B agency project usually lands with a one-line ask: "set up payment terms for our wholesale buyers." It sounds like a half-day config task. Then you ask who gets Net 60 and the answer is "it depends," followed by ten minutes of exceptions nobody has written down.

That gap is the real project. The client doesn't have a payment terms problem, they have an unwritten credit policy, and checkout can't enforce something that only exists in the sales director's head.

This post is how I'd scope that work: the discovery questions to ask, how to turn the answers into rules, how to move buyers off draft orders, how to test and hand off, and what to leave native.

Why B2B payment terms projects get underscoped

Most quotes for this work price the visible part. Assign terms to company locations, maybe install an app, train someone. That part is quick.

What blows the budget is discovery that happens by accident. You set every wholesale location to Net 30, the client looks at it in week two and says "no, the Fosters account gets 60, and new accounts pay upfront until they've ordered twice, unless sales vouches for them." Each of those is a rule. Each rule is a conversation with finance you didn't price.

The fix is to run that conversation first and make it the first billable deliverable. A written payment terms policy, agreed by finance and sales, is worth more to the client than the configuration that follows it. It's also the thing that lets you quote the rest with a straight face.

The discovery questions to ask before you scope B2B payment terms

Run these with finance and sales in the same room. When they disagree, you've found the rules that matter most.

• Who gets terms today? Get a list, not a description. Which companies pay on Net terms, which pay upfront, which pay on fulfillment.
• How is it decided? Order size, how long they've been a customer, product category, a credit check, a gut call from the account manager. Write down every factor someone mentions.
• Where does the policy live? A spreadsheet, an ERP, an email thread from 2023, or people's heads. If it's heads, plan extra discovery time.
• Who can grant an exception? And how is it recorded today. Exceptions are where verbal policies drift the most.
• What happens on a first order? New accounts are often the strictest rule and the least documented one.
• Are deposits involved? A percentage, a fixed amount, only above a certain order size.
• How do orders come in now? Self-serve checkout, draft orders created by sales, or both. This decides how big the migration step is.

The answer to "where does it live" sets the scope more than anything else. A clean spreadsheet with one row per account is a few hours of mapping. A policy that exists only as "ask Dave" is a few workshops.

Turning a verbal credit policy into enforceable rules

Once you have the answers, rewrite them as if-then statements. Every rule has the same shape: when these conditions are all true, apply these terms.

If a set of conditions match, then apply the defined terms and any deposit.

Here's a typical policy as a client would say it: "New accounts pay half upfront. Our gold wholesale accounts get Net 60 on big orders. Everyone else who's ordered before gets Net 30."

As rules, checked top to bottom, first match wins:

Three things come out of this exercise that the client didn't have before. The threshold is a number ($25,000), not "big orders." The order matters, because a gold account's first order hits rule 1 before rule 2. And there's a decision about what happens to an order that matches nothing, which most verbal policies never answer.

Ask about the edges while you're writing these. Is $25,000 "or more" or "more than"? Does a gold account placing a $24,000 order fall to Net 30, and is finance fine with that? Those answers go in the policy document, signed off, before anything goes live.

If the client wants terms per company or location rather than per tag, the difference between a company and a company location is worth walking them through, because terms on Shopify Plus attach to the location.

What to leave native and what needs an app

Be honest with the client here. It's the part of scoping that builds the most trust.

Shopify Plus handles static terms natively. You assign one of eight templates to each company location under Customers → Companies: Net 7, 15, 30, 45, 60 or 90, Due on Fulfillment, or no terms. You can also set a deposit percentage on the location. Every order from that location gets those terms.

If the client's policy is "each account has one fixed arrangement," leave it native. No app, no extra cost, fewer moving parts. I'd tell a client that even if it shrinks the project.

Native stops working when terms need to change order to order. Shopify reads the location record at checkout. It doesn't look at the cart total, the buyer's order history, or the products in the cart. A policy like the three rules above needs something running at checkout that evaluates them, which on Plus means a Payment Customization Function, either one you build or an app that ships one. The build vs buy breakdown for agencies covers that decision in detail.

Also scope out what neither path does well. If the policy depends on a live outstanding balance or overdue invoices, checkout rules can't read that from your client's accounting system on their own. The usual answer is a process: finance tags an account credit-hold and a rule at the top of the list catches it.

Moving buyers off draft orders

Many clients come to this project because their sales team creates a draft order for every B2B purchase and sets the terms by hand. The migration is less about software and more about sequencing.

1. List every buyer currently on draft orders, with the terms they actually get today. This often surfaces exceptions the discovery session missed.
2. Map each buyer to a rule. If a buyer doesn't fit any rule, either the policy gets a new rule or the buyer gets told their terms are changing. Both are client decisions, not yours.
3. Move a small group first. Pick five or ten accounts, have them order through checkout, and keep draft orders available for everyone else.
4. Keep draft orders for true one-offs. Custom quotes and negotiated deals can stay manual. The goal is that routine reorders never need a person.

The draft orders vs rules-based terms comparison is a useful thing to send the client's sales lead before this step, so they know what changes for them.

Testing and handing off a B2B payment terms project

Testing is where you prove the rules match the signed-off policy. Build a scenario table from the policy document: the buyer, the order total, whether it's their first order, and the terms finance expects. Then run every row.

Push on the edges. Test a gold account at $24,999, $25,000 and $25,001. Test a gold account's first order. Test a buyer that matches nothing. The full approach is in testing B2B payment rules before they go live.

The handoff package is three things: the written policy, the rules as configured, and the scenario table with expected results. When finance changes the policy next quarter, the client updates the document, changes the rule, and reruns the table. If they can't do that without calling you, the handoff isn't finished.

When native terms aren't enough for an agency client

For clients whose policy needs more than static location terms, this is the gap TermStack was built for. It's a no-code rules engine for B2B payment terms on Shopify Plus, and the three rules above are configured as written: first order, customer tag, order total, and order count as conditions, with Net terms, due on fulfillment, and deposits as outcomes.

The parts that matter for agencies are the ones around the rules. The Simulator runs your scenario table against draft rules before they publish. Version history means a bad publish rolls back in one click. The audit log records who changed what, which answers finance's first question after go-live.

If you scope these projects regularly, the TermStack partner program pays 30% of the subscription revenue from clients you refer, for 24 months, and gives you a free Growth-tier sandbox on a development store to build and test rulesets before the client installs. Details are on the partner page.

Frequently asked questions

Summary

Scope a B2B payment terms project around the policy, not the configuration. Run discovery with finance and sales together, write the policy as numbered if-then rules, leave static per-account terms native, and use an app only where terms need to change order to order. Migrate off draft orders in small groups, and hand off the policy, the rules, and a scenario table the client can rerun.

• Try the live demo store → to see payment terms rules applying at a real B2B checkout.
• Want help mapping a client's policy into rules? I'll do it with you on a free 30-minute call: their policy, tested in the Simulator and live at checkout before the call ends. Email termstack@varrlabs.com.

When the policy outgrows static location terms, TermStack gives your client rules they can test, roll back, and audit without calling you every time finance changes its mind.