Tranche payment structures exist for a reason. Releasing funds in stages, conditional on demonstrated progress, is how funders maintain accountability for public or philanthropic money without requiring grantees to front-load all their costs. Done well, tranched payments give grantees predictable cash flow while giving funders genuine checkpoints.
Done poorly, they create a different problem: a spreadsheet with a column for "Milestone Status" that nobody trusts, a finance team that releases payments based on an email from the grants team, and an audit trail that exists only in someone's inbox.
This article is for grants officers and finance managers who run tranche payment schedules and are looking for a more reliable way to connect milestone evidence, approval, and payment release. It focuses on the design decisions that make milestone-based payments actually work.
The theory is straightforward. A grant agreement specifies two or three payment tranches. Each tranche is tied to a milestone: a deliverable, a report, an expenditure threshold, or a combination. The grantee completes the work, submits evidence, the funder reviews it, approves it, and releases the next tranche.
That sequence does three things simultaneously. It keeps the grantee focused on agreed deliverables rather than just spending. It gives the funder regular assurance that the funded activity is on track. And it creates a natural record of progress that feeds accountability reporting at the end of the grant period.
The problem is that the sequence only works if each step is actually connected to the next. If milestone approval lives in one place and payment release lives in another, the connection between them is a manual step — and manual steps get missed, delayed, or completed out of order.
There are four failure modes that appear consistently in tranche payment management when it is handled outside a purpose-built system:
Milestone status and payment status drift apart. A grantee submits milestone evidence. The grants officer reviews it, approves it, and updates a spreadsheet. Two weeks later, finance runs the payment batch but uses a different spreadsheet, or the same spreadsheet with a filter that excludes the recently approved row. The payment is missed. The grantee follows up. The grants officer checks with finance. The payment is released three weeks late.
Evidence is stored separately from approval. The grantee emails a report. The grants officer downloads it to a shared drive. The approval is recorded in the grants management system (or the spreadsheet). When the accountability audit comes, someone has to reassemble the evidence file from three locations.
Conditional milestones are not enforced. The grant agreement says Tranche 3 requires both a progress report and evidence of at least 80% expenditure of Tranche 2. In a spreadsheet, that condition is a note in a cell. Nothing prevents Tranche 3 from being released if one condition is unmet — it depends on the person processing the payment remembering to check.
The audit trail is incomplete. If someone outside your team asks who approved a particular milestone and when, the answer should be a timestamped record in the grants system. If the answer is "let me check my email," the audit trail is not a trail; it is a reconstruction.
Before thinking about tracking systems, the milestones themselves need to be designed to be evidenceable. A milestone that cannot be clearly evidenced cannot be reliably approved. And a milestone that is vague enough that any evidence will satisfy it is not really a milestone at all.
Useful milestone design follows three principles:
Be specific about what evidence is required. "Progress report" is not a milestone. "A progress report covering expenditure to date, activities completed against the work plan, and narrative on any variances from budget" is a milestone. The specificity is what allows reviewers to assess whether the submission actually satisfies the condition.
Specify the format and submission method. If grantees can submit via email, shared link, or file upload to different staff members, your evidence collection will be fragmented. A consistent submission channel — ideally a structured form or portal that captures the evidence in a standard format — makes review more efficient and the record cleaner.
Match the milestone to something the grantee controls. Milestones tied to external factors (a government decision, a third-party publication) create disputes about whether the condition has been met. Milestones tied to the grantee's own work and deliverables are straightforward to assess.
For multi-year grants, it is also worth considering whether the milestones are distributed appropriately across the grant period. A common failure is front-loading the meaningful milestone obligations in Year 1, then having a Year 3 payment that is effectively unconditional because the grantee has met all the substantive milestones already.
Once evidence is submitted, the approval workflow needs to answer four questions before payment can proceed:
In many organisations, questions 1 through 3 are managed informally — a grants officer reviews the submission and sends an email saying it looks fine. Question 4 happens when the finance team processes the batch. There is no documented link between the review and the payment.
A structured evidence review workflow assigns the review to a named person, requires them to record a finding against each milestone condition, and only moves the application to a payable status once the review is complete and approved. That process should generate a permanent record: who reviewed, what they found, when they approved.
For larger grants or higher-value tranches, it is worth building a two-step approval into the workflow — grants officer review followed by programme manager sign-off. The threshold for two-step approval should be specified in your delegations schedule.
This is where most manual systems fail. Milestone approval and payment release are treated as separate processes managed by separate teams, with a handoff between them that depends on someone remembering to send a message.
The reliable design connects them structurally: when a milestone is approved in the grants system, a payment is created in the finance system automatically. No CSV export. No re-entry. No email to the finance team asking them to add it to the next run.
Tahua's integration with Xero works this way. When a milestone is approved, a Xero bill is created automatically, pre-populated with the grantee's details, the payment amount, and the relevant grant reference. Finance reviews and approves the bill in Xero. The payment goes out. The reconciliation record links back to the milestone approval in Tahua.
Acorn Foundation, which distributes $5.1M annually across 500+ donor-advised funds, reduced its payment processing time from one week to one day using this workflow. The reduction is almost entirely explained by eliminating the manual handoff between milestone tracking and payment creation.
"Xero integration" is a term that covers a range of different things. At the minimum end, it means a CSV export formatted for Xero upload. At the maximum end, it means a bidirectional connection where payment status in Xero updates the grant record in the grants management system.
For milestone-based payment workflows, the relevant capability is the automatic creation of a payable record in Xero when a milestone is approved. This removes the manual handoff and ensures that every approved milestone generates a corresponding record in the finance system — with no possibility of the records drifting out of sync.
The Xero record also provides the finance team with the information they need to review and approve the payment without referring back to the grants team for context. The bill includes the grant reference, the milestone description, the grantee name and bank details, and the approved amount. Finance has everything they need in the system they already use.
For reconciliation, the Xero payment record provides confirmation of the transaction date and method, which closes the audit trail on the payment side. The grants system record holds the milestone evidence and approval; the Xero record holds the payment confirmation.
Not all milestone submissions are approved on first review. A grantee submits a progress report that doesn't address a required element. The reviewer requests additional information. The grantee resubmits. This is a normal part of grants administration. The challenge is managing it without losing track of the original submission or the reviewer's feedback.
A dispute or resubmission workflow needs to preserve:
If your system allows grantees to overwrite their original submission, or if reviewer feedback exists only in an email thread, the audit trail for that milestone is incomplete. When a dispute arises — at a later date, with a different team member involved — it will be much harder to establish what was submitted, what was requested, and what was eventually approved.
The practical design is to treat each submission as an immutable record and use a status workflow (Submitted, Under Review, Returned for Amendment, Resubmitted, Approved) rather than allowing records to be edited in place.
For high-value or contested milestones, it is also worth documenting the basis for the approval decision explicitly in the review record — not just "approved" but "approved based on evidence of X, which satisfies condition Y in the grant agreement." That documentation supports your position if the decision is queried later.
Milestone-based payments done well are one of the most effective accountability tools in grants management. They create structure for grantees, clarity for reviewers, and a complete record for your programme. Getting there requires connecting the evidence, the approval, and the payment in a single traceable workflow rather than three separate processes.
To see how that workflow operates end-to-end — from milestone submission through Xero payment creation — book a 30-minute demo.