Contract

​

What a contract is

A contract is the source of truth for a customer’s billing relationship in Zenskar. It holds a customer, a business entity, a currency, a start date, and one or more line items, each representing a product the customer is being billed for. Every invoice the contract generates is derived from the contract and stays in sync with it. Changing the contract reshapes affected invoices automatically rather than requiring manual reconciliation. This is a deliberate shift from Zenskar’s previous contract model, where you acted as the orchestrator, setting up products, wiring entitlements, watching invoices, and reaching for credit notes whenever reality drifted from the contract. In this model, the contract holds the full timeline of past, present, and future invoices. Change a price retroactively and Zenskar reshapes the affected invoice on its own, adds correction line items where needed, and keeps accounting entries in sync.

​

Line items

Each product added to a contract becomes a line item. A single contract can carry multiple line items, for example a flat monthly platform fee and a pay-per-use API charge on the same contract. Each line item carries its own pricing, price versions, billing schedule, discounts, and commitments, so different products on the same contract can behave completely differently from one another.

​

Price versions

A line item is not limited to a single price for its whole lifetime. You can attach several price versions, each covering its own date range, so a rate can change partway through the contract without needing a new line item, for example $10 per seat for the first half of the year and$12 per seat from the second half onward. Zenskar requires these versions to fully cover the line item’s dates with no gaps and no overlaps.

​

How products get added to a contract

Zenskar is designed to build a contract from your organization’s default pricing for the products you add, without you having to pick a rate for each one individually. Right now, though, you always pick products and their pricing yourself; there is no auto-populate option in the product selection screen yet.

​

Line item classification: point-in-time vs. period-of-time

Every line item carries one classification, and this single piece of information drives proration, entitlement deduction, accounting treatment, and revenue recognition for that line. A simple test for which classification applies: if the customer did not use the product yesterday, would they still owe for yesterday? If yes, like a gym membership or a subscription, it is POT. If no, because no event fired, so no charge applies, it is PIT.

​

Anchor dates

By default, a line item’s billing cycle starts from its own start date. An anchor date lets you align billing to a different, fixed point instead, for example the last day of every month, regardless of when the line item itself started. Anchor dates can be set at the contract level, the line item level, or both. A line item’s own anchor dates take precedence over the contract’s for that line item’s span; the contract’s anchor dates are the fallback wherever a line item does not specify its own. Within a single anchor date list, contract or line item, the entries have to be internally consistent: they cannot overlap, and a dated entry cannot be mixed with an undated one in the same list. This does not mean two different line items on the same contract are required to share the same anchor; they are free to run on independent schedules.

​

Why the contract holding the truth matters

Because every invoice stays wired to the contract, edits propagate downstream automatically:

• Add, remove, or update line items without voiding the original deal.
• Adjust commitments mid-contract: raise or lower minimums, change evaluation mode, extend the commitment window.
• Apply amendments from a specific date forward, and let Zenskar reshape every affected invoice without manual credit notes or reconciliation.

​

Concurrency and auditability

If two people edit the same contract at the same time, the second save is rejected with a conflict error rather than silently overwriting the first person’s changes. This is checked using a version number carried on the contract: your save has to state which version you started from, and if someone else has already saved a newer version, yours is rejected so you can reload and reapply your change. Most entries that make up a contract, a price version, a quantity change, also carry their own audit stamp of who set it and when. Anchor dates are the exception: they track which level, contract or line item, a value was inherited from, but not who set it or when.

​

What a contract does not yet support

Some contract-level capabilities are not available yet:

• Quantities are configured at the line item level; contract-level quantity controls are not supported.
• Optional line items (turned on or off mid-contract, like premium support billed only when activated) have a place reserved for them in the data model, but there is no way to mark a line item optional or to activate one from the interface yet.
• Discounts and minimum commitments work at the line item level only; contract-level discounts and commitments are not available yet.
• Tags are not available on contracts. Custom attributes exist in the underlying data model, but there is no way to set or edit them from the interface yet, so treat them as unavailable for now, unlike on products and customers, where custom attributes are fully usable.
• Only one rule for how retroactive billing changes affect invoices can be active on a contract at a time. Adding a second, date-ranged rule on top of an existing one is not available yet. See invoice corrections for what this rule controls.
• Building a brand-new price from scratch for a single line item, rather than reusing one already in your catalog, is not available. The option appears in the interface but is shown disabled.
• The customer on a contract cannot be changed after the contract is created. Create a new contract if the customer was wrong.
• Contract-level settings such as billing address, shipping address, invoice template, and payment method are not available yet.
• A dedicated contract amendment history (a readable log of what changed on a contract over time, beyond its current version number) does not exist yet.
• Lifecycle states such as trial periods, eternal contracts, expiry, pause or suspend, and auto-renewal are not configurable yet. A contract only ever has two statuses: draft and active.
• Billing a parent customer or a designated third-party payer for a child customer’s contract is not supported yet.