If you manage grants in New Zealand or Australia, you have almost certainly used SmartyGrants or evaluated it. It has a large installed base, strong sector familiarity, and a form builder that many practitioners learned on. That is not a trivial foundation.
But a pattern keeps appearing in conversations with experienced grants managers: the platform handles intake well. Once a grant is approved and the real work starts — contracts, milestone reporting, payment releases, accountability documents — that work migrates to a spreadsheet. Sometimes two spreadsheets. Occasionally a shared drive folder and a whiteboard.
This article is for the grants manager or operations lead who has recognised that pattern in their own organisation and is trying to think clearly about what to look for next. It is not a takedown of SmartyGrants. It is a framework for the evaluation question that actually matters: does the platform you're considering cover the full grant lifecycle, or does it hand off to your spreadsheet at the moment the complexity begins?
Start here, because evaluating an alternative without being honest about the incumbent's strengths is a waste of time.
SmartyGrants built its position by solving a real problem: collecting applications at scale without requiring technical staff to build intake infrastructure from scratch. Its form builder is mature. The sector knows it. Many applicant organisations have SmartyGrants logins already, which reduces onboarding friction. Assessors are familiar with the interface.
For organisations whose primary operational challenge is still managing inbound applications — dealing with volume, scoring consistently, communicating outcomes — SmartyGrants covers that well.
The honest question is what happens after that.
Post-award is where grants management gets genuinely complex. The moment you issue a contract, your obligation to the grantee and your accountability to the funder (or to the Crown) changes materially. You are now tracking:
None of those tasks is a form-collection problem. They are workflow, document, and financial management problems. And they require the same audit trail — who approved what, when, based on what evidence — that a well-run grants function demands.
The gap shows up when an organisation tries to answer a simple question: "Which of our current grantees are overdue on a milestone, and what is the dollar value of the payment that depends on it?" If the answer requires opening a spreadsheet, that is not a technology limitation of the grants sector broadly. It is a capability gap in the platform being used.
When you are evaluating alternatives — whether that is Tahua, a different platform, or a custom build — these are the questions that separate intake tools from lifecycle platforms:
1. Does post-award management live inside the platform, or does it require integration with a separate tool?
Ask to see milestone tracking, contract management, and accountability reporting in a live demo. If those features are roadmap items or require a third-party plugin, note that.
2. How does the platform handle payment processing?
Specifically: does payment release require re-entering data in your finance system, or does approval in the grants platform create the payable transaction automatically?
3. What does the audit trail look like?
For government agencies and publicly-accountable organisations, immutable audit logs are not optional. Ask to see the audit record for a completed grant — who approved each stage, what documents were attached, and whether that record can be exported for an OIA request or an audit.
4. Where does the data live, and who has access to it?
For NZ government agencies in particular, data residency matters. Ask specifically which AWS region hosts the data and whether it ever transits through offshore infrastructure.
5. What does implementation actually look like?
Ask for a reference from an organisation of similar size. Ask how long implementation took and what migration support was provided. Vendor answers to this question are far less reliable than direct references.
One of the more specific capability questions on the list above is whether payment approval in the grants platform creates the transaction in your finance system automatically. This matters because manual re-entry is not just slower — it introduces an error point and breaks the audit trail.
The payment workflow in Tahua works as follows: when a milestone is approved by the grants manager, an invoice is automatically created in Xero as a payable, with the audit document attached. Grantee contacts are created or mapped automatically in Xero so no contact data needs to be re-entered. When payment is processed in Xero, the status updates back in Tahua. The full record — milestone approval, invoice creation, payment confirmation — sits in one audit trail.
Acorn Foundation moved from a payment cycle that took up to a week to one that takes a single day. They manage more than 500 donor funds and distribute $5.1 million annually. The 60% reduction in admin time the team reports is attributable primarily to this payment workflow.
Te Māngai Pāho, the Māori broadcasting funding agency, is a Crown entity processing a high volume of grant rounds with strict accountability requirements. The capability question for an organisation like Te Māngai Pāho is not whether the platform can collect applications — it is whether it can handle multiple concurrent grant rounds while maintaining the audit rigour that Crown accountability requires.
Since implementing Tahua, Te Māngai Pāho has doubled the number of grant rounds it can run concurrently. The audit trail requirement is addressed at the platform level: every action — application received, assessment recorded, decision made, payment released — is logged with an immutable timestamp and the identity of the person who took the action.
For NZ government agencies, iwi organisations, and Crown entities, data residency is not a vendor selection nicety. It is a compliance requirement.
Tahua hosts all data in AWS Sydney Region. Data does not transit through offshore infrastructure. The security architecture aligns with NZISM (New Zealand Information Security Manual) requirements, uses AES-256 encryption at rest, and maintains immutable audit logs.
This is directly relevant to the OIA question. If your grants data sits in a platform hosted offshore, an OIA request that requires producing a complete audit record creates a complication that should be addressed before it becomes a problem.
If your organisation is subject to NZ government information security requirements, the relevant detail is on the government grants management page.
Once you have answered the five questions above, the evaluation itself should test the specific workflows your organisation needs to run, not the vendor's preferred demo flow.
Prepare three scenarios before any product demonstration:
Scenario 1 — A milestone dispute. A grantee submits evidence for a milestone. Your assessor determines it is not sufficient. Walk through how the platform handles that exchange: the rejection, the resubmission, the approval, and the payment trigger. Ask what the audit trail looks like at the end of that process.
Scenario 2 — A concurrent round view. If you run multiple grant rounds simultaneously, ask to see how the platform presents that. Can a grants manager get a single view of all open milestones across all active rounds? Can a finance lead see all pending payment approvals without navigating round by round?
Scenario 3 — An audit export. Ask the vendor to export a complete grant record — from application through to final payment — in a format you could hand to an auditor. If that export requires a support ticket or custom development, that is a meaningful data point.
One reason organisations stay on platforms past the point of fit is the perceived difficulty of migration. It is worth being specific about what that actually involves.
A typical Tahua implementation runs 6–8 weeks. The phases are roughly: weeks 1–2 for configuration and data migration, weeks 3–4 for team training, weeks 5–6 for parallel testing and go-live, and weeks 7 onwards for optimisation. Historical data from the previous platform is migrated as part of the process — active grants, historical records, and grantee contacts.
The relevant risk management question is not "is migration hard" but "what is the cost of staying on a platform that requires a parallel spreadsheet for every post-award process?" That cost compounds with each grant round.
If post-award management is your gap, book a 30-minute walkthrough — we'll show you the milestone-to-payment workflow specifically.