5.10 Payment calculation
5.10.1 Purpose The payment calculation is stage 3 of the invoice workflow. It takes the verified invoice amount from measurement and applies the commercial terms configured on the trade — discount, retentions, securities, and cash discount...
5.10.1 Purpose
The payment calculation is stage 3 of the invoice workflow. It takes the verified invoice amount from measurement and applies the commercial terms configured on the trade — discount, retentions, securities, and cash discount — to arrive at the amount payable. It also serves as the invoice cover sheet for the subcontractor and can be exported as a PDF.
Note: This screen is reached from the Supplier info button on the measurement stage, and corresponds to what earlier documentation calls the supplier information sheet or subcontractor cover sheet.
5.10.2 Header and payment amounts
Figure 48 — The payment calculation
The header identifies the subcontractor, trade, reference (AZ number), invoice number, invoice date, and performance period. Controls are Refresh, PDF, and Finalize.
Note: Before finalisation, Transferred is editable here. After finalisation it becomes read-only on this screen and is reconciled on the Payments screen instead — see sections 5.10.8 and 5.11. Either way, a payment discrepancy is corrected forward against the next invoice rather than by reopening a finalised invoice.
5.10.3 The calculation table
The calculation is presented as a numbered sequence of lines, each with net, VAT, and gross columns. The lines observed are:
In the captured example the sequence resolved as follows:
Caution: This worked example indicates that the performance retention is applied to the subtotal after the discount, rather than to the verified invoice amount. That reading is consistent with the captured figures but is inferred from a single example. Have the development team confirm the order of operations before it is stated as fact or used in training.
5.10.4 Contract security
A panel beside the calculation summarises how the security configured on the trade is being applied.
A second panel shows the security calculation: the applied percentage, the required security, any lodged guarantees, and the resulting open security. Further down, the amount capped and withheld on this invoice is shown.
Note: This panel is where the Contract performance security settings from section 5.6.5 become visible in operation — including whether supplements are included in the base, which is the With amendments setting on the trade.
5.10.5 Invoice overview
The Invoice overview panel compares, position by position, what was contracted, what was invoiced, and what was measured. Show all and Exceeding LV switch between all positions and only those exceeding the contracted quantity.
Figure 49 — The invoice overview and payment lines
Totals for invoice amount, verified amount, deviation, and deviation percentage are shown beneath the positions. A supplements panel lists supplements for the trade, or states that there are none.
Note: A correction can be positive as well as negative. Where the measured quantity exceeds the invoiced quantity, the verified amount is higher than the invoice amount and the correction increases the payment.
5.10.6 Ticket details
Beneath the invoice overview, deductions arising from tickets are listed by category, each with a ticket count and a value.
Figure 50 — Ticket details feeding the payment calculation
The categories observed are: Defects, Damages, Counterclaims, Provisional retentions, Contractual penalties, Contract performance guarantees, Warranty bonds, and Corrections. Each can be expanded to show the underlying tickets.
Note: This is the link between the Tickets module and billing. Several of these categories correspond directly to deduction lines in the calculation table, so a ticket raised against a trade becomes a deduction on that trade’s next payment.
Tickets are raised and categorised in the Tickets module; see section 5.12. Only tickets in Approved status are included in this calculation.
5.10.7 Finalising the invoice
Finalize completes the payment calculation and moves the invoice to stage 4. A confirmation dialog states what finalisation does.
Figure 51 — The finalisation confirmation
Caution: Finalisation cannot be undone by the user. Because immutability here is a compliance requirement rather than a convenience, do not describe it in training as something support can reverse. Confirm with the development team what, if anything, can be done about an invoice finalised in error.
Before finalisation the calculation shows a banner indicating that the displayed version has just been computed and not yet saved. Use Refresh to recompute, and PDF to export the cover sheet.
5.10.8 After finalisation
Figure 52 — The payment calculation after finalisation
Once the invoice is finalised:
- A confirmation message names the invoice and its AZ reference.
- Stage 4, Finalize, is marked complete in the workflow stepper.
- The Finalize control is removed from the header; Refresh and PDF remain.
- The Transferred amount is no longer editable on this screen. Its description changes to state that it is reconciled on the Payments screen.
Note: This is an important correction to how the Transferred field behaves. Before finalisation it is editable directly on the payment calculation. After finalisation the amount is still adjustable, but only through the Payments screen described in section 5.11. The ability to record what was actually paid is relocated, not removed.