Skip to main content

​
Why a correction is needed at all

An approved invoice is a financial record, so Zenskar never edits one directly. When a retroactive change to a contract, a price change, a quantity change, a new discount, affects a period that has already been invoiced and approved, Zenskar works out the difference and applies it separately instead of rewriting history. Which direction that difference runs determines what happens next.

​
When the customer was undercharged

If the change means the customer should have paid more for an already-approved period, Zenskar delivers the difference in one of two ways:
  • By default, a separate invoice, dated back to the original period, is raised for just the difference.
  • A contract can instead be configured so the difference is added to the customer’s next regular invoice rather than raised as its own back-dated document.

​
When the customer was overcharged

If the change means the customer should have paid less, the reduction is carried forward and offsets the customer’s upcoming invoices, appearing as smaller future invoices rather than a standalone document, by default.
The contract’s own invoicing config has a setting for delivering an overcharge correction as a standalone credit note instead of carrying it forward, but that setting does nothing if reached: Zenskar accepts it without error but does not act on it, and the correction is still carried forward as reduced future invoices, silently. Do not rely on this setting to produce a credit note.
A standalone credit note can still be issued and applied against the affected invoice, but as a separate, manual action from the customer or invoice page rather than something the contract’s invoicing config triggers automatically.

​
What’s not configurable yet

Which of the two undercharge behaviors applies is set per contract, using a single active rule at a time. The dashboard currently allows only one such rule per contract, even though the contract itself can hold more than one behind the scenes. For overcharges, carrying forward is the only option the invoicing config can actually produce today; there is no equivalent switch in the interface for reaching a standalone credit note automatically. See the contract reference for how this is represented.