A Day That Skips Only the Holidays
Somewhere in a Singapore construction contract there is a clause about progress payments, and somewhere in the Building and Construction Industry Security of Payment Act 2004 there is a chain of eight dated steps that runs whether the clause exists or not. Miss one of them by a day and you lose a right rather than a discount. So the interesting question is not what the deadlines are. It is what the Act means by a day — and it means something that no date field in ordinary software is set up to count.
The short version, first
Section 2 defines a day, for the purposes of the whole Act, as any day other than a public holiday within the meaning of the Holidays Act 1998. Not a working day. Not a business day. Saturdays and Sundays count; gazetted holidays do not. That is a third unit of time, and this product implements exactly two of them: plain calendar days, and working days that skip both the weekend and the holidays. The ingredient for the third — the tenant's own holiday set, resolved for a year — is already a public method with nothing calling it that way. Meanwhile the chain hangs off the service of a document, and the two clocks we can already run and escalate both start counting the moment a record is created.
Eight steps, and every one of them is dated
The Act builds an escalation ladder out of nothing but dates and documents. A subcontractor serves a payment claim. The main contractor must answer it with a payment response. If it does not answer, or answers with a number the claimant does not accept in writing, a short cooling-off window opens, and at the end of it a right to adjudicate appears. That right expires in a week. What follows is a compressed arbitration with its own deadlines, ending in a determination that has to be paid within a week of being served.
Read as a process, it is a workflow with eight steps and a legal consequence attached to each transition. Read as data, it is eight dates, each derived from a document event rather than from a calendar.
-
The claim is served
One payment claim per progress payment, under section 10(1). It must be served by the date the contract specifies, or by a date the Regulations prescribe if the contract says nothing — and in any event not later than thirty months after the work was last carried out.
-
The response is due
Section 11(1)(a): by the date in the contract, or within twenty-one days of service, whichever is earlier. Note the direction of that comparison — a contract cannot buy the respondent more time, only less. Where the contract is silent, fourteen days.
-
The payment falls due
Section 8(1)(b): the earlier of the contract's own date and thirty-five days after either the day a tax invoice was submitted, where the claimant is registered for GST and has submitted one, or the response date under section 11(1) — and explicitly whether or not a response was actually provided. Fourteen days where the contract sets no due date at all.
-
The dispute settlement period runs
Seven days after the section 11(1) response date, under section 12(6). A window for the parties to talk, in which the respondent may still provide the response it failed to provide.
-
The right to adjudicate arises
At the end of that window, if the dispute is unsettled or the response never came. Section 12(3) is worth reading twice: a claimant is considered to dispute a payment response if the claimant does not accept it in writing. Silence is a dispute.
-
The application is lodged
Within seven days after the right first arises, under section 13(3)(a) — and only after a written notice of intention has been given to the respondent under section 13(2). Two documents, in order, inside one week.
-
The adjudication runs
The respondent lodges its response within seven days of receiving a copy of the application. The adjudication commences the instant that window expires. The adjudicator then has seven days where the respondent both failed to respond and failed to lodge, and fourteen days in any other case, unless the parties agree to extend.
-
The determination is paid
Within seven days after it is served, or by the date the adjudicator set, whichever is later. Section 22(1). And section 36 makes every one of the steps above survive a contract clause that tries to exclude, modify or restrict it.
What the Act means by a day
"day" means any day other than a public holiday within the meaning of the Holidays Act 1998
That is section 2, and it governs every number in the ladder above. It is a single line and it is the most consequential line in the Act for anybody writing software against it, because it describes a unit that sits between the two units everybody has. A calendar count includes the holidays. A working-day count excludes the weekends as well. The statutory day excludes the holidays and keeps the weekends, so a seven-day window that contains a Saturday, a Sunday and one gazetted holiday is nine calendar days long and no other number.
It also outsources the list. The Act does not enumerate the holidays; it points at the Holidays Act 1998, which means the set of excluded days is maintained elsewhere and gazetted, and several of the days on it are fixed by lunar or lunisolar reckoning rather than by a date. A holiday table that repeats an entry on the same month and day every year gets the first year right and drifts after that — which is a problem we have written up in its own right, from a different country, in <a href="/blog/a-holiday-that-moves">A Holiday That Moves</a>. Here it is a dependency rather than the subject: get the list wrong and every deadline in the ladder is wrong by the same amount, quietly.
Five phrases the Act defines, and what each one rules out
The phrase The definition, and what it excludes
Day The unit every deadline is counted in
Any day other than a public holiday under the Holidays Act 1998. Weekends are days. So this is not a business-day count, and a system offering you calendar days or business days is offering you two wrong answers.
Due date When the money is payable
The date a progress payment becomes due and payable under section 8 — a date the Act computes, not a date on your invoice. Where the contract sets one, the Act takes whichever of the two is earlier.
Payment response The answer to a claim
A response to a payment claim made by the respondent under section 11(1) or 12(4). Its due date is the anchor for two later clocks, and section 8(1)(b)(ii) runs from it whether or not a response is provided — so failing to answer does not stop the count.
Dispute settlement period The cooling-off window
The period of seven days after the date on which, or the period within which, the payment response is required under section 11(1). Measured from the deadline, not from anything that happened.
Pay when paid provision The clause that does not work
A provision, by whatever name, making one party's liability contingent on being paid by a third party — or making the due date contingent on that payment. Section 9(1) makes it unenforceable and of no effect.
The last one is the shape most upstream contracts are written in, and it is the one the Act is most emphatic about. A due date derived from when your own customer pays you is not a due date under this Act; it is a clause with no effect, and the statutory date runs underneath it regardless.
Twenty-nine of the numbers are parameters, not constants
Section 39 is a single sentence that lists every period in the Act the Minister may change by order in the Gazette, and there are twenty-nine provision references in it: the due-date periods in section 8, the claim window in 10(2)(b), both response periods in 11(1), the dispute settlement period in 12(6), the application window in 13(3)(a), the appointment and response periods in 14 and 15, both determination periods in 17(1), the review periods in 18, 18A and 19, five separate payment periods in 22, and the enforcement periods in 24, 25 and 26. Every one of them is substitutable without amending the Act. Which is a direct instruction to anybody modelling this: the numbers are configuration and the structure is code. Hard-code twenty-one and fourteen into a workflow and you have written down a value the statute itself treats as adjustable.
Three modules here, three answers to "when is this due"
A chain of deadlines is not an exotic requirement. This product already runs deadlines with escalation in three separate places, and they answer the question differently enough that it is worth laying them side by side before deciding which one a payment claim would live in.
The three deadline mechanisms already in the product
| What the mechanism does | Helpdesk tickets | Workflow tasks | Project tasks |
|---|---|---|---|
| Holds a response deadline and a resolution deadline separately | Yes | Yes | No |
| Deadline length is stored as tenant data rather than in code | Yes | Partly — configurable by you | Yes |
| Can count on the organization's working calendar instead of the wall clock | Yes | No | No |
| Counts from a business event rather than from record creation | Partly — configurable by you | No | Yes |
| Escalates and reports a breach on its own schedule | Yes | Yes | Partly — configurable by you |
| Can pause and resume without losing the remaining time | Yes | No | No |
| Notices when the deadline lands on a holiday | Yes | Partly — configurable by you | Yes |
| Counts in a unit that skips holidays but keeps weekends | No | No | No |
Built and maintained Configurable by you, not maintained by us Not built
The bottom row is the Act's unit and no column has it. The row above it is more interesting than it looks: the projects module does notice — it warns you when a task's due date falls on the assignee's leave or a public holiday — and then leaves the date exactly where you put it, which is the right behaviour for a plan and the wrong behaviour for a statutory deadline.
The helpdesk clock is the most complete of the three. Each category carries its own first-response and resolution targets in minutes, plus a setting that chooses between elapsed time and business hours; on the business setting the arithmetic goes through the organization's working calendar, and a ticket paused while waiting on the requester resumes with the time it had left rather than a fresh span. The workflow clock is the one with the structure and not the calendar: a task carries a response deadline, a resolution deadline and an escalation policy, and all three are computed as plain minutes added to the moment the task was created. The default lengths are a small table keyed on priority — sixty minutes and eight hours for high, four hours and a day otherwise — sitting in code, though the method that applies them will accept an override from whatever created the task.
And the workflow rule engine has a date language, which is where the two-units problem is most visible. You can write <code>today+7</code> or <code>today-7</code> for calendar days, and <code>today+2b</code> for business days; the validation message says exactly that. Two suffixes, two conventions, and the statutory day is neither. It is also a language for asking questions rather than setting dates — the grammar is parsed on the comparison side of a condition, so it can test whether a date has passed a threshold and it does not compute a deadline to store.
One seven-day window, counted three ways
One unit expires the right early and the other believes it still exists after it has gone, and the second error is much worse than the first. The weekend count and the holiday are this example's assumptions; your window has whatever it has, which changes the arithmetic and not the conclusion. Nothing on either side of that spread reports a problem, because both counters are doing precisely what they were asked to do.
The clock starts on a document we do not date
Section 8(1)(b)(i) runs the thirty-five days from the day a tax invoice was submitted to the respondent, where the claimant is registered for GST and has submitted one — and section 8(6) protects that timing, letting the claimant submit at any time after the payment response, despite anything in the contract to the contrary. So on the purchase side of this arrangement, the date that starts the longest clock in the ladder is the date a supplier document arrived. We hold a supplier invoice as a link on the order and there is no field for the day it turned up. That is the same missing date we found starting a different statutory clock in <a href="/blog/the-day-the-invoice-arrived">The Day the Invoice Arrived</a> — there it decided a reporting figure, here it decides a deadline, and it is one column in both cases.
The ladder, against what exists
A sequence of steps, each with a deadline and an owner
The workflow module runs exactly this shape: a task per step, a response deadline, a resolution deadline, an escalation policy, and a log of what happened when.
Deadlines that count on the organization's own calendar
The working calendar resolves one answer for the whole tenant — the configured working week and the tenant's public holidays — and the helpdesk clock counts on it.
A holiday list, per organization, expandable across years
A public method returns the tenant's holidays as a set of dates for a year span, which is precisely the ingredient a holidays-only count needs.
A count that skips holidays and keeps weekends
The two units available are calendar days and business days; the third convention this Act uses would be a small addition on top of the holiday set that already exists.
A deadline anchored on a document event
Workflow deadlines run from the moment the task record was created. Running them from the day a claim was served, or an invoice submitted, is a change of anchor rather than a new clock.
Deadline lengths as tenant configuration
Helpdesk targets live in the category row; workflow task defaults live in a table keyed on priority in code, with an override accepted from the caller.
A date on the arrival of a supplier document
A supplier invoice is held as a link against the order, so the day it was received — the anchor for the longest period in this Act — would be a new column.
A statutory clock is four small things, in this order
None of these is a module, and the sequence matters — the last one is only meaningful once the first three exist.
A third counting unit
A day count that consults the holiday set and ignores the working week. The holiday set is already a public method returning dates for a year span; this is a loop over it with the weekend rule left out.
A deadline anchored on an event
So a step's clock starts when a document was served or received rather than when somebody created the record. One nullable anchor column and one decision about what to do when it is empty.
Deadline lengths as configuration
Each step in a chain carrying its own number and its own unit, held as tenant data. Section 39 of this Act is the argument for it: the legislature treats its own periods as adjustable.
A received date on a supplier document
The day a supplier invoice arrived, as a date rather than a link — which starts the longest clock here and settles a reporting question in another jurisdiction at the same time.
The first is arithmetic and the second is a column. The third is the one worth scoping properly, because it is the difference between a chain you configure and a chain somebody redeploys. The fourth we would take alongside any of them.
Tell us what your operation needsFour questions for a system that will hold a statutory deadline
What units can a due date be expressed in?
What you will probably hear
Calendar days, and business days if you configure a calendar.
How to read it
Those are the two everybody has, and this Act needs a third. Ask specifically whether the holiday list and the working-week rule can be applied independently of each other, because that is the whole question. If holidays are only reachable through a business-day helper, the answer is no however good the calendar is.
What does the deadline count from?
What you will probably hear
From when the record was created, or from a date you enter.
How to read it
A typed date is fine and a creation timestamp is not, because the statutory anchor is the service of a document by someone else. Ask what happens when the document arrives on Tuesday and gets entered on Friday — whether the clock knows the difference, and whether it can be back-dated without an audit trail.
Where do the numbers live?
What you will probably hear
In the workflow definition, or in a settings screen.
How to read it
Ask whether changing twenty-one days to eighteen is a form or a deployment. Section 39 of this Act lists twenty-nine provision references the Minister can change by gazette order, so the question is not hypothetical, and a system with the periods in code will be correct right up until the day it is not.
What happens when a deadline is missed?
What you will probably hear
A notification, and a report of overdue items.
How to read it
Adequate for a service target and thin for a lapsed right. Ask what the record looks like afterwards: whether the missed date is preserved rather than recalculated, whether a pause moves it, and whether anybody can move it silently. Under this Act a missed window destroys an entitlement, so the audit value of the old date is higher than the operational value of the new one.
What AWRA OpsHub does today
- A step-by-step chain with a deadline on each step, in the workflow module — a response deadline, a resolution deadline, an escalation policy and an event log per task.
- One working calendar for the whole organization, resolving the configured working week and the tenant's public holidays, so leave arithmetic, workflow due dates and support clocks give the same answer.
- A per-tenant holiday list, with recurring and one-off entries, returned as a set of dates for any year span.
- Support deadlines in two modes, elapsed time or business hours, chosen per category and counted on the working calendar in the second mode.
- A support clock that pauses and resumes correctly, carrying the remaining time forward rather than restarting the span, and refusing to un-breach a deadline that had already passed.
- A warning when a task's due date lands badly, raised when the assignee is on approved leave or the date is a public holiday.
- Business-day arithmetic for workflow dates, with an escape hatch for an organization that needs a genuinely separate calendar for one purpose.
More we can add to your workspace
- A day count that skips public holidays and keeps weekends, which is the unit this Act defines and the one a claim ladder has to be counted in.
- A deadline that starts on a document event, so a step counts from the day a claim was served or an invoice submitted rather than from the moment its record was created.
- Deadline lengths held as tenant configuration on each step of a chain, with the unit stored beside the number, so a gazetted change to a period is an edit rather than a release.
- A received date on a supplier invoice, as a date column on the order rather than a link to a document.
- A holiday entry defined by a rule rather than a date, for the days set by lunar or lunisolar reckoning and announced annually.
- A preserved history of a deadline that moved, so the original date and the reason for the change survive alongside the current one.
- A chain that stops the ladder when a window closes, marking a right as lapsed rather than leaving a task overdue and open.
Where we point you to a specialist
- We will not tell you whether your contract is a construction contract or a supply contract within the meaning of this Act, and the answer changes the numbers substantially — sixty days against thirty-five, thirty against fourteen. Section 3 and section 4 decide it, together with a list of excluded agreements, and that is a construction lawyer's question rather than a configuration question. We read those sections far enough to know they change the arithmetic and no further.
- We will not compute a statutory deadline and present it as the deadline. Software can count days on whichever unit you tell it to, and we would rather build the unit and show the arithmetic than produce a date that looks authoritative. Whether the claim was validly served, whether the response was a payment response, whether a right has arisen — all of those precede the counting, and a party who misses a window loses an entitlement. The date is ours to calculate and the reliance is yours to place.
- We hold a position on where the numbers belong, and it is the one the Act takes about itself: in configuration. Section 39 exists precisely because the legislature expects to move them. A quotation from us for this work will put the periods in tenant data, and we would push back on a specification that asked for them in code even though it is quicker.
The first item is arithmetic over a set of dates we already assemble, and it is the smallest of the seven. The second is a nullable column and a decision about what an empty anchor means. The fourth is one column and pays for itself twice, because it also settles the late-payment reporting question we ran into in Britain. The third is the one that wants a proper conversation, since it is the difference between a chain your administrator configures and a chain that needs a release. The fifth belongs with the holiday work generally rather than with this Act, and the sixth and seventh follow naturally once a step knows which window it is in.
Tell us which deadlines you are actually counting
If your operation runs against periods defined in a statute rather than in a service agreement, the unit and the anchor are the two things worth checking before anything else — and both are usually smaller work than they sound. A monthly valuation cycle is a different shape again, and we looked at one in <a href="/blog/three-days-after-the-month-ends">Three Days After the Month Ends</a>; if your constraint is the plan rather than the payment, <a href="/blog/a-dependency-type-the-critical-path-ignores">the critical path's view of a weekend</a> is the nearer question.
Talk to us about your workspace