The Payment Certificate Is Cumulative. Almost Every System Assumes It Is Not.
· 9 min read · Faceela
An interim payment certificate values the entire job from day one, then subtracts everything certified before it. It is not a bill for the month, and that single difference is where most systems break.
The shape never varies. You submit a payment application stating the cumulative value of work executed, plus approved variations to date, plus materials on site where the contract allows. From that gross valuation the consultant deducts retention to date and advance recovered to date, reaching net certified to date. Only the last step — less previously certified — makes the document look monthly. What remains is payable.
Two consequences follow, and they are the ones software gets wrong. A quantity remeasured downwards in month seven needs no credit note: the current valuation simply states the corrected figure and the arithmetic self-corrects. And the certificate is written by the consultant rather than by you, so what you applied for and what was certified are two separate records that must both survive.
That is the whole answer. The rest of this article is why it is hard to hold in a system, and how to make a vendor prove they can hold it.
An IPC values the whole job, every time
Written out, the shape is always this:
| Value of work executed to date | the whole job, remeasured |
| Plus approved variations to date | cumulative, not this month's |
| Plus materials on site, if the contract allows | |
| Gross valuation to date | |
| Less retention to date | a running balance, not a monthly charge |
| Less advance recovered to date | |
| Net certified to date | |
| Less previously certified | everything up to the last certificate |
| Payable this certificate |
Every line above the last one says to date. Only the final subtraction makes it look monthly.
This is not a stylistic convention that a system could reasonably normalise away. It is load-bearing, and three ordinary events prove it.
A quantity is remeasured downwards. The consultant agrees in month seven that the blockwork in month three was overmeasured. In a cumulative certificate this is not a credit note and not an adjustment line. The current valuation simply states the corrected quantity, the gross to date comes out lower than it would have, and the arithmetic self-corrects. In a monthly-invoice model you have to raise a negative document against a closed period, and someone has to decide what that does to a VAT return that was already filed.
A variation is approved at a lower value than instructed. Same mechanism. The cumulative variation total reflects the approved figure, and every certificate after it carries the corrected number. No reversal is required because nothing was ever asserted as final.
A certificate is issued for less than was applied for. The most common event of all, and the one that decides whether your system is a record or a fiction. More on it below.
A system that models the certificate as a monthly invoice can be made to survive the first of these with a credit note, the second with a manual journal, and the third with an email. It survives all three at once by growing a spreadsheet.
Application and certificate are two documents, and you own one of them
The vocabulary here gets used loosely on site and the looseness costs money in a systems conversation.
You prepare and submit a payment application — sometimes called the statement or the valuation. It carries your measurement, your variation claims, your materials on site.
Someone else — the engineer, the consultant, the client's QS — assesses it and issues the interim payment certificate. That document carries their number.
The two are not the same document at different stages of approval. They are two records, authored by two parties, that must both persist. This matters because the difference between them is a business fact with a life of several months: a quantity the consultant will not accept yet, a variation that needs more backup, a materials-on-site claim rejected for want of an invoice.
If your system stores only the certified figure, that difference exists nowhere, and the only person who knows the running total of what you applied for and did not get is whoever keeps the file. If your system stores only the application and treats certification as an approval flag, your revenue is your own opinion of your revenue.
The requirement is unglamorous and absolute: two documents, linked, both with their own values, both queryable. What did we apply for cumulatively, what has been certified cumulatively, and what is the gap by cause.
The deductions block is a category, not a line
Under the gross valuation sits a block that gets flattened, in most implementations, into a single "deductions" number. It contains at least three different things with three different behaviours, and collapsing them is how a contractor ends up unable to answer a question about their own balance sheet.
Retention is withheld money that comes back. It accrues at a percentage against a cap, and it is released in stages tied to completion and the end of the defects period. It sits on the balance sheet the whole time. It is not an expense and never was.
Advance recovery is repayment of money you already received. It is a loan amortising against a schedule in the contract, often with a threshold before recovery begins. It reduces a liability, and when the last of it is recovered the recovery stops — which the system has to know without being told each month.
Back-charges and contra-charges are costs you incurred on someone else's behalf, coming back the other way. On the client-facing certificate these are rarer; on the subcontract certificates you issue, they are constant and they are the single most commonly ungoverned document in contracting.
Three categories, three ledgers, three sets of release or exhaustion conditions. One "deductions" column serves none of them, and the tell is simple: ask what your total retention receivable is today, across all contracts, with release dates. If the answer requires someone to open a file, the block was flattened.
Applied versus certified, and where the difference is allowed to live
A contractor of any size is carrying, at all times, a running gap between what they have applied for and what has been certified. That gap is not an error. It is the normal state of the commercial relationship, and it is made of specific, nameable items.
The system question is only this: does each item in the gap have a name, an owner and an age?
The failure mode is a single figure. "We are 2.1 million adrift on certification" is a fact that produces no action. The same 2.1 million split into a quantity dispute on two BOQ lines, three variations awaiting the consultant's assessment, and a materials-on-site claim that was rejected for a missing delivery note produces three different phone calls to three different people, two of which will be resolved this week.
The aging is the second half. A rejected line that is four certificates old is not a dispute any more; it is a decision someone made not to pursue, without saying so. Systems make that visible by carrying the item forward with its original date. Spreadsheets make it invisible by being retyped each month, which quietly resets every age to zero.
Three dates, and the one that starts the clock
A certificate cycle has at least three dates, and they get conflated constantly.
The application date is when you submit. The certification date is when the certificate is issued. The due date for payment is calculated from one of those two, and which one — plus how many days — is written in the particular conditions of your contract, not in the general conditions and not in any standard form's default.
That last point is worth being pedantic about. UAE construction contracts are commonly based on a FIDIC form with the particular conditions amended, and payment periods are one of the most reliably amended provisions. Any system, template or article that hardcodes a number of days is describing somebody else's contract. The system requirement is that the period is a field on the contract, and that ageing runs from the correct one of the three dates.
Get this wrong and your receivables ageing is wrong in a specific and expensive direction: certificates look overdue that are not, so nobody trusts the report, so nobody uses it, so the ones that genuinely are overdue get chased by whoever happens to remember.
What this means when the tax invoice has to be a data file
UAE e-invoicing arrives on a published timetable: voluntary from 1 July 2026, then mandatory in stages — businesses at or above AED 50 million in annual revenue appoint an Accredited Service Provider by 30 October 2026 and go live on 1 January 2027, below that threshold appointment by 31 March 2027 and go-live on 1 July 2027, government entities on 1 October 2027, with a penalty of AED 5,000 per month for failing to appoint or implement on time. B2B and B2G are in scope; B2C is not.
For a contractor the deadline lands in an awkward place, and the reason is the shape of the document rather than the technology. Your tax invoice is generated from a certificate that carries measured quantities, a retention deduction, an advance recovery, and often a variation annexure. To transmit that as structured data, it has to exist as structured data first.
Which is the whole argument of this article arriving from a different direction. A certificate assembled in Excel and re-keyed into the ledger as one revenue line cannot be transmitted as a structured document, because the structure was thrown away at the point of re-keying. The fix is not an e-invoicing project. The fix is that the certificate is calculated in the system, with every deduction a derived field rather than a typed one — and then the transmission piece is an integration, which is what it should have been.
Dates and thresholds above are from the UAE Ministry of Finance e-invoicing programme, checked on 12 August 2026.
How to make a vendor prove it
Demonstrations are built to show a product's best hour. The way to get past that is to make the demonstration follow a contract instead of a script, and the certificate is the sharpest place to do it because everything hard about contracting is visible in one document.
- Produce a certificate for a partial quantity on three BOQ lines, then produce the next one and show that the second states cumulative value and subtracts the first — without a manual entry carrying the previous total across.
- Remeasure one of those lines downwards on the third certificate. Watch what document gets raised. If the answer is a credit note, the model is monthly.
- Certify at a value lower than applied. Ask where the difference is now stored, whether it carries an age, and how it appears on the next application.
- Show retention balance and release schedule as a query, not a journal.
- Apply advance recovery at the contractual rate and show the outstanding advance afterwards. Then run enough certificates to exhaust it and confirm recovery stops on its own.
- Change the payment period on the contract and show the receivables ageing move.
Anything that cannot be done in front of you is configuration you have not been quoted, a module you have not been sold, or a spreadsheet with a longer life expectancy than the project. The go-live risk assessment covers the rest of what decides whether an implementation survives its first year, and the full picture of what a contractor's system has to produce puts the certificate back among the other three numbers it belongs with.
The short version
The certificate is the contractor's revenue event, and it is cumulative, externally authored, and structurally unlike an invoice in ways that are not negotiable by configuration.
Standard products do not contain it. That is not a scandal, and we have set out exactly which parts of it Odoo lacks despite being an Odoo partner, because the honest gap map is more useful than a feature list. What matters is that whoever you appoint says out loud which of the three it is: the product ships a certificate, a partner's module produces one, or somebody is going to write it for you.
All three answers are workable. Only the unspoken fourth one — that everyone assumed a module existed — reliably costs a year. If a build is the right answer, the thing to insist on is software written for you that keeps its upgrade path, owned as a component rather than as one developer's private patch set. The rest of what this looks like in practice, with named references, is on the contracting page.