Entity settings
Some configuration lives on the record itself: a customer's payment terms, a subscription's billing timing, a plan's dunning policy. These usually start from a default you set once, and then belong to that record.
The question that decides how they behave is when the default was read.
Stamped, or read live
Two mechanisms, and confusing them produces the most common settings complaint: "I changed the default and nothing happened."
| What happens | Changing the default later | |
|---|---|---|
| Stamped at create | The default is copied onto the record when it is created | Affects new records only |
| Read at use | The default is looked up each time it is needed | Affects everything, immediately |
A subscription's billing timing, anchor day, auto-renew and version tracking are stamped. The subscription carries its own copy from the moment it exists. Changing the organization default afterwards changes nothing for it.
A subscription's proration mode, line grouping and price resolution policy are read live. Change the default and every subscription follows at once.
Changing a default does not fix existing records
For anything stamped, the fix is to update the records themselves, not the default. The default only shapes what gets created next.
The wallet cascade
Wallets show the pattern most clearly, because all three levels exist.
Code
A new wallet takes its credit limit, low-balance threshold, maximum balance and auto-topup from the customer's defaults, which themselves came from the organization's. All of that happens at creation. Editing a customer's defaults later does not touch wallets that already exist.
The due-date ladder
When an invoice is due is decided by the most specific rule that has an answer:
Code
The customer-type profile outranks the organization setting
A BUSINESS or CONSUMER customer picks up payment terms from its type
profile, which sits above the organization-level value. Setting the
organization default and seeing no change on typed customers is this, not a bug.
What is configured where
| Entity | Configuration it carries |
|---|---|
| Customer | Payment terms, prepaid or postpaid mode, wallet defaults, currency, locale, preferred payment provider, e-invoicing preference |
| Subscription | Billing timing, anchor day, auto-renew, proration mode, version tracking, payment terms |
| Plan | Its own dunning policy, price cadence, whether product versions are followed or pinned |
| Product | Tax category, pricing model, unit label |
| Meter | Late-event policy, deduplication, window |
| Checkout link | What to collect, and the defaults the resulting subscription is created with |
Toggles that no longer exist
Named here so nobody goes looking, or asks for them back:
auto_finalize_invoices, send_payment_reminders and tax_inclusive were
removed as subscription settings. Invoicing behaviour is decided by the plan and
the billing cycle; tax inclusivity is a property of the tax rule.
Reference
| Topic | When you need it |
|---|---|
| Settings | The scope model these defaults come from |
| Organization settings | Where the organization-level defaults live |
| Wallets | The limits the cascade above configures |