If you are tracking grant milestones in a spreadsheet, you are probably tracking them quite carefully. You have a tab per grantee, or a row per milestone, or a colour-coded status column. You update it after every email exchange. You check it before every payment run.
And yet something has gone wrong — or almost went wrong. A payment was released before a milestone report arrived. An overdue accountability report sat in the queue for three weeks before anyone noticed. A grantee claimed a milestone was complete, and you had no clear record of whether it had been approved.
The problem is not the spreadsheet. The problem is what a spreadsheet cannot do.
A milestone is not just a date. It is a conditional relationship between a deliverable and a payment: the money moves only if the deliverable has been accepted as complete. That sounds simple, but the full set of requirements around it is more involved than a date column can capture.
Effective milestone tracking requires:
A spreadsheet records the date. It does not enforce the condition, trigger the reminder, structure the submission, or produce the approval record. The person managing the spreadsheet performs all of those functions manually — which means the system is only as reliable as the person's memory, availability, and workload at any given time.
Failure mode 1: Payment released before milestone is approved. The finance team runs payments on a schedule. The spreadsheet shows a milestone as "due." The programme officer intended to follow up but had not yet reviewed the report. The payment goes out. By the time anyone notices, the next milestone is already approaching.
Failure mode 2: Overdue report goes unnoticed. No one is automatically notified when a milestone passes without a submission. The programme officer who managed that grant has been on leave. The spreadsheet shows "outstanding" in the status column, but no one has looked at that column this month. Three months later, the report arrives — or it doesn't.
Failure mode 3: Approval is verbal and unrecorded. A grantee calls to confirm their milestone report was received. The programme officer says it looks fine. The payment is processed. Eighteen months later, during an audit, there is no record of who approved that milestone or on what basis. The approval was real; the record is not.
Failure mode 4: Information lives in the wrong place. The original grant application, the funding agreement, the milestone schedule, and the accountability reports are in four different locations — email, SharePoint, the spreadsheet, and possibly a paper file. When something goes wrong, reconstructing the full record takes hours and produces an incomplete picture.
In a purpose-built grants management system, the milestone-to-payment workflow is a connected sequence of enforced steps, not a series of manual actions.
When a grant is awarded, the milestone schedule is set up in the system and attached to the grant record — the same record that holds the application, the assessment, and the contract. Each milestone has a description, a due date, and a defined evidence requirement.
When the due date approaches, the system notifies the grantee automatically. The grantee submits their milestone report — whether a form, a document upload, or both — through the same portal they used to apply. The submission is logged against the milestone record and the programme officer is notified.
The programme officer reviews the submission in the system. They approve it or return it with feedback. The approval is timestamped and attributed to their user account. Only once the milestone is marked as approved does the payment workflow become available.
When Tahua's Xero integration is active, that approval creates a bill in Xero automatically. The finance team sees a bill that corresponds to an approved milestone — there is no manual data entry, no email to prompt the payment, and no possibility of the payment being processed before the milestone is accepted.
This is the structural difference. The spreadsheet records what happened. The system enforces what can happen.
Accountability reporting is the final obligation in the grants lifecycle, and it is frequently the most poorly managed — not because organisations do not care about it, but because it happens after the payment has been made and the pressure has shifted elsewhere.
In a spreadsheet-based system, accountability reports are chased by email. Whether they have arrived, whether they meet the requirements, and what they said is recorded in a spreadsheet or a shared folder that is increasingly difficult to maintain as the portfolio grows.
In a connected system, accountability reporting is a milestone. It has a due date, a submission mechanism, a review workflow, and a record. The grantee submits through the portal. The programme officer reviews against the original funding objectives — which are accessible in the same system, not in a separate folder. The report is linked to the grant record for the life of the fund.
This matters for compliance, for learning, and for board reporting. When a trustee or a funder asks "what did we fund, and did it achieve what we intended?", the answer should not require a manual audit of emails and shared drives.
Programme teams often see the problem clearly. Finance teams sometimes need more convincing, because from a finance perspective, the existing payment process works: the instruction arrives, the payment goes out, the record is reconciled. The problem — that the instruction should not have been sent because the milestone was not approved — is invisible to the payment process.
The case to a finance team is straightforward: milestone-conditional payments reduce the risk of grants being paid without evidence of delivery. When milestone approval creates a Xero bill automatically, the finance team processes a structured, approved payment rather than interpreting an email instruction. The audit record is cleaner. The payment run is faster. Reconciliation is simpler.
The Acorn Foundation saw payment processing time drop from one week to one day after implementing structured milestone-to-payment workflows. The efficiency gain was not because the team worked faster; it was because the process itself was shorter. No manual data transfer, no email chains, no cross-referencing a spreadsheet with a payment schedule.
Transitioning from spreadsheet-based milestone management to a dedicated system is less disruptive than most teams expect, provided it is done thoughtfully.
A few practical points:
Migrate active grants selectively. You do not need to retroactively enter historical grants into the new system. Start with new grants awarded after the go-live date. Bring in active grants that have remaining milestones, and keep the spreadsheet as a read-only archive for closed grants.
Align milestone structure with your existing agreements. The milestones you enter into the system should reflect the conditions in your signed funding agreements. If your agreements are vague on milestone definitions, that is worth addressing before — not after — you set up the system.
Involve your finance team early. If you are using a Xero integration, your finance team needs to know that bills will appear from the grants system. Agree the workflow before go-live: who approves the bill in Xero, what the naming convention is, and how the payment is coded.
Run one round in parallel before you retire the spreadsheet. For high-stakes programmes, overlap for one payment cycle so you can verify that the system and the spreadsheet agree before you stop maintaining the latter.
The goal is not to replace one form of manual work with a more complex system. It is to replace manual enforcement with structural enforcement — so that the conditions of a grant are met because the system requires it, not because someone remembered to check.
To see the milestone-to-payment workflow in a live platform, book a 30-minute demo.