An invoice type is a template governing how invoices of that kind behave. It is where policy lives: whether an invoice can be edited after creation, whether it publishes automatically, whether several can exist for one job.
Getting these switches right is what stops invoicing being a matter of individual discipline.
The settings
| Field | What it does |
|---|---|
| Name | What operators pick. |
| Invoice type code | Its identifier. |
| Load type | Which traffic it applies to — FCL, LCL, air. |
| Shipping type | Import or export. |
| Sales tax group | The default tax treatment for invoices of this type. |
| Allow update | Whether an invoice of this type can be edited after creation. |
| Allow multiple | Whether more than one invoice of this type can exist for the same job. |
| Publish on create | Whether it publishes immediately rather than waiting for review. |
| Ceil total amount | Whether the total is rounded up. |
| Cost lines pickable | Whether the operator chooses which cost lines to include. |
| Skip publish policy | Whether the normal publish approval is bypassed. |
| Match charge lines | Whether lines are matched against the quotation's charge lines. |
| Apply validity policy | Whether the type is date-bounded — see below. |
| Cost line source | Where lines come from by default. |
| Sort order | Position in the list operators choose from. |
| Active | Whether the type is offered at all. |
| Preconditions | Checks that must pass before an invoice of this type is created. |
| Post-actions | What happens automatically afterwards. |
Two configurations that are rejected outright
costLinesPickableandallowUpdatecannot both be on — "Invalid configuration: when costLinesPickable allowUpdate must be disabled". If the operator picks the lines, the invoice cannot then be edited; the choice is made once.
applyValidityPolicyrequires avalidTo— "validTo is required for invoice types with applyValidityPolicy enabled".
Validity policy and storage days
Apply validity policy makes the type date-bounded, and it is what enables storage-day computation: "Storage days can only be computed for invoice types with applyValidityPolicy enabled".
If a storage or demurrage invoice is not calculating days, this flag is the first thing to check — before the tariff, before the units. The related failure "Storage to date or storage from date not found" means the flag is right but the dates on the shipment are missing.
The switches that matter most
Allow update. Off is the safer default for anything customer-facing. An invoice that cannot be edited after creation forces corrections through credit notes, which is where they belong — see Credit notes. Turn it on only for internal or draft-stage types.
Allow multiple. Off prevents the classic double-billing failure, where a job is invoiced twice because two people did it. Turn it on deliberately, for genuinely instalment-billed or split-billed work.
Publish on create and skip publish policy together decide how much human review sits between creating an invoice and issuing it. Both on means invoices go out with no check. That is right for high-volume standard traffic and wrong for anything unusual. Consider a separate type for the traffic that needs eyes on it, rather than switching review off globally.
Match charge lines. When on, invoice lines are matched against the charge lines agreed on the quotation. This is the control that catches the gap between what you quoted and what you are billing. Leave it on unless there is a specific reason not to — it is the cheapest customer-dispute prevention available.
Ceil total amount rounds the invoice total up. Check this is what your customers and your tax authority expect before enabling it; rounding rules are a common source of small, persistent reconciliation differences.
Cost lines pickable lets the operator choose which cost lines are included. Useful where one job is billed across several invoices; a source of omissions where it is not needed.
Preconditions and post-actions
Preconditions are checks that must pass before an invoice of this type can be created — a way to require that a shipment has reached a certain point, or that required data exists, before it can be billed.
Post-actions are what runs afterwards, in the same spirit as workflow transitions: notifications, document generation, onward submission. See Running a transition for the same pattern applied to shipments.
Designing your type set
- One type per genuinely different billing policy, not one per customer. Types are policy, not personalisation.
- Name them so the choice is obvious at creation. The operator picking the type is deciding whether the invoice can later be edited, and they will not read the configuration.
- Start restrictive. Allow update off, allow multiple off, match charge lines on. Relax individual switches when a real case demands it, rather than starting permissive and hoping.
- Review the tax group. The sales tax group on the type is what invoices default to, and a wrong default is applied silently to every invoice of that kind.
Last updated 13 September 2026