A Due Date That Gates Nothing
A milestone here is a name, a due date, a status and a sort order. It groups tasks and it is the only level between a task and a project that reports cleanly — and nothing anywhere is gated, triggered or alerted by it.
The position, stated first
Milestones are useful here and they are organisational rather than contractual. Use them as your reporting level, because the task hierarchy does not aggregate and this does. Do not build a billing process around them: nothing fires when one is reached, and no invoice knows they exist.
A milestone in a plan and a milestone in a contract are two different objects that share a word. One organises work. The other releases money. Software almost always builds the first and buyers almost always hear the second.
What it is
Four fields that matter: a name, a due date, a status, and an ordering. Tasks belong to it. It survives a project being cloned — remapped to the copy rather than cleared, unlike sprints — so it is durable structure rather than a period.
That durability is the tell. Somebody decided a milestone is part of how the work is shaped, not part of when it happened.
Why it is more useful than it looks
Because it is the only aggregation level this module has.
Tasks can have subtasks, and the hierarchy does not add anything up — a parent shows its own numbers, never its children's. So the levels available for reporting are the individual task and the whole project, with nothing in between.
Except the milestone. Group by it and you get a middle layer: how is this phase doing, rather than how is this task or how is this project. For most projects, that middle layer is where management actually happens.
What each level can tell you
| Level | Groups tasks | Aggregates numbers | Gates anything |
|---|---|---|---|
| Task | No | No | Partly — configurable by you |
| Parent task | Yes | No | No |
| Milestone | Yes | Yes | No |
| Sprint | Yes | Partly — configurable by you | No |
| Project | Yes | Yes | Yes |
Built and maintained Configurable by you, not maintained by us Not built
Only the project gates anything, through its status machine. The "part" on a task is the seal on an invoiced or paid-out time entry, which is a refusal at the entry rather than at the task.
The milestone due date is the most authoritative-looking date in the module and the only one nothing watches.
What nothing does with it
There is no refusal to mark a milestone complete while its tasks are open. Its status is set by a person rather than derived from the work underneath it.
Its due date raises no alert. This product has a real habit of scheduled reminders — idle stock, expiring batches, employee documents, lapsing supplier qualifications, breached support deadlines — and a milestone due date is not among them. A date passes and nothing happens.
And nothing connects it to an invoice. There is no amount on a milestone, and no invoice references one. A milestone-billed contract is administered by a person watching a plan and raising invoices at the right moments.
One thing not to confuse it with
There is a project payout in this product — a record with a reference, a status, a currency, a total, an approver and a posted date. It is money going out, to the people who did the work, and it is a genuine feature. It is not milestone billing, and it does not face a customer.
What AWRA OpsHub does today
- Milestones with a name, a due date, a status and an explicit sort order.
- Tasks belonging to a milestone, giving the only working intermediate reporting level.
- Milestones remapped rather than cleared when a project is cloned, so they are durable structure.
- Project payouts — money out to the team — with a reference, an approver and a posted date.
- Time entries sealed once attached to a payout, edits refused.
What it does not do
- Any amount, value or deliverable on a milestone.
- Any link between a milestone and a customer invoice.
- Any refusal to complete a milestone with open tasks.
- Any milestone status derived from the tasks underneath it.
- Any alert or reminder on a milestone due date.
- Any approval on reaching a milestone.
Not ours, by choice
- Milestones being organisational rather than contractual is a reasonable scope. It becomes a problem only when somebody assumes the word means what it means in their contract, which it usually does.
- The absence of a due-date reminder is the odd one, because this product has scheduled reminders for six other kinds of date. A milestone date is arguably the most visible date in a project and nothing watches it.
- Nothing here is Australian, New Zealand or Pacific. Oceania is here because dispersed delivery across long distances makes phase completion the natural reporting unit — the thing head office actually asks about.
Two, and the first is genuinely small
The date exists and the reminder machinery exists. They have simply never been introduced.
A milestone due-date reminder
A warning ahead of the date, to the project owner, using the same scheduled-reminder machinery that already runs daily for stock, batches, documents, supplier qualifications and tickets. This is the cheapest useful thing on this page and it is conspicuously absent.
Milestone billing
An amount on a milestone and an invoice raised from reaching it, with the milestone recorded on the invoice. This is the contractual version of the word and it is a real build — the value, the trigger, the approval and the link all have to be designed rather than added.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your contracts bill on milestones, raise the second before a trial.
Talk to us about milestone billingFour questions about milestones
Does a milestone carry a value?
A good answer sounds like
Yes, if it bills.
What it actually means
Ours does not. Without an amount, milestone billing is a person with a calendar.
What happens when a milestone due date passes?
A good answer sounds like
Somebody is told.
What it actually means
Ours does nothing, in a product that reminds you about six other kinds of date.
Can I complete a milestone with open tasks?
A good answer sounds like
No.
What it actually means
Ours permits it, so a milestone status is a claim rather than a computed fact.
Is the milestone on the invoice?
A good answer sounds like
Yes, as a reference.
What it actually means
Without it, reconciling billed milestones against delivered ones is manual forever.
Report by milestone, bill by hand
Use them as the reporting layer the task tree cannot give you, and keep the billing calendar somewhere that will actually remind you — because this will not.
Talk about project phasesFrequently asked questions
Should I use milestones or parent tasks to group work?
Milestones, for anything you want a number about — they are the only intermediate level that aggregates. Parent tasks are for arranging a screen, since the hierarchy does not add anything up.
Can I invoice for a milestone?
You can raise an invoice when a milestone is reached, as a person doing it. Nothing links the two records, so reconciling what was billed against what was delivered is a manual comparison.
What is a project payout?
Money out to the people who did the work, with an approver and a posted date, and time entries sealed once attached to one. It is a real and useful feature and it faces your team rather than your customer.
