Payment terms
Payment terms are how many days a customer has to pay — what turns an invoice date into a due date.
Which setting wins
Four things are consulted, and the first that is set wins:
- The customer's own payment terms.
- If they have none, their customer account's.
- If neither, the payment method's default terms.
- If nothing is set anywhere, 30 days.
So an individual buyer can be given different terms from the rest of their business, and those terms win. The account is the fallback for its buyers, not an override of them.
This runs the opposite way to invoicing
Worth pausing on, because the two chains look similar and behave oppositely.
| Setting | Which wins |
|---|---|
| Payment terms | The customer's own beats their account's |
| Invoicing strategy | The account's override beats the channel's default |
For payment terms the individual is stronger. For invoicing the account is. Assuming one shape for both will be wrong in one of them.
The reasoning is sensible enough once seen: terms are a concession you might extend to one buyer, while invoicing is about how a business wants its paperwork and should not vary by which person placed the order. See invoicing strategies.
The 30-day fallback
Where nothing in the chain is set, 30 days applies. So an order always has a due date, even for a brand-new customer nobody has configured.
When the method is not yet known
An order taken as payment-due-later may have no transaction against it at the point it is confirmed, so its payment method is unknown. The chain then rests on the customer, the account, or the fallback.
Where terms are used
To work out the due date on a deferred order — one being paid later rather than at checkout. An order paid at the point of sale has nothing to defer.
Setting them
On the customer for an individual arrangement, or on the customer account for the business as a whole. The account is where it usually belongs; the customer is for the exception.