Your Funding Agreements Contain Obligations Nobody Has Ever Listed. That's an Extraction Job.
Your Funding Agreements Contain Obligations Nobody Has Ever Listed. That's an Extraction Job.
Clause-level extraction into a fixed schema across documents you already own is one of the few things language models do reliably. Here's the shape of the work, and the two decisions you must never hand over.
A mid-sized not-for-profit, NDIS provider or community organisation typically holds somewhere between five and fifty active funding agreements, service agreements and grant deeds. Each one has its own acquittal timing, its own reporting triggers, its own variation and notification clauses, its own treatment of unspent funds, its own termination notice period, and its own view on who owns an asset bought with the money.
Almost nobody holds a single register of those obligations.
This is not negligence and it is not unusual. It is arithmetic. Reading thirty deeds properly and tabulating what each one requires is roughly a fortnight of concentrated work by someone senior enough to understand what they are reading — and that person's fortnight is always needed somewhere with a deadline attached. So the register never gets built, and the organisation runs instead on a distributed memory: the program manager who knows their own acquittal date, the finance officer who remembers that one funder wants a variation notice, the CEO who has a general sense of the notice periods.
That works until someone leaves, a funder changes contact, or two obligations land in the same week.
Why this is the right shape of problem for a model
A lot of AI-in-finance discussion is about tasks that models are mediocre at — judgement, novel reasoning, deciding what matters. This is not one of those.
Clause-level extraction into a fixed schema, across a defined document set, in a domain with fairly standardised drafting, is close to the ideal case. The document exists. The answer is in it. The schema tells the model exactly what to look for. Every output has a source you can point at, which means every output is checkable in seconds rather than argued about.
It is also the case where the value is unambiguous, because the alternative isn't a worse register — it's no register at all. You are not replacing a good process. You are making a process exist that has never existed, because the manual version was never going to be funded.
Fix the schema before you touch a document
The single biggest determinant of whether this works is that the schema is decided first and does not change mid-run. A schema that evolves as you go produces a register where the first ten agreements were captured against different questions from the last twenty, which is worse than no register because it looks complete.
The fields any funding register needs are not exotic. Broadly:
Identity. Funder, agreement name, reference number, execution date, term start and end, total value, payment schedule.
Money conditions. What triggers a payment. Whether funds are advanced or in arrears. What happens to unspent funds at period end and at term end — repayable, rollover-with-approval, or retained.
Reporting. Every report the agreement requires, with its due date or trigger, its recipient, and whether it requires audited figures or a signed declaration. This field alone usually produces the biggest surprise.
Notification and variation. What you are obliged to tell the funder about, and within what period. Changes in key personnel, changes in service delivery, adverse events, insolvency indicators, changes of control.
Assets and intellectual property. Who owns what was bought or created with the money, and what happens to it at the end.
Termination and survival. Notice periods on both sides, termination for convenience, and which obligations survive the end of the agreement — record retention especially.
Provenance. For every extracted value: the clause number and the page. Non-negotiable. A register without provenance cannot be verified, and an unverifiable register is a liability wearing the costume of a control.
The extraction pass, and the verification pass that isn't optional
Run one agreement at a time against the fixed schema. Not all thirty in one go — batching invites the model to smooth across documents, and the whole point is that these agreements differ.
Then verify. Not "review" — verify, with a defined method, and budget real time for it. My rule of thumb is that verification takes about a third of the time the extraction saved, which still leaves you enormously ahead, and any approach that claims to need less than that is selling something.
Three checks do most of the work:
Spot-check every field type at least once, across different agreements. Errors in this kind of work are not random; they cluster by field. If the model has misread how one deed expresses a notice period, it has probably misread the others drafted the same way. One confirmed error in a field is a reason to check that field everywhere, not to fix the one.
Check every field where the model returned nothing. Blanks are where the failures hide, and they are the least likely cells to attract attention because a blank looks like an answer.
Check 100% of the fields with money or dates in them. Every value, against the clause. These are the fields that will be relied on, and they are fast to check because provenance points you straight at the text.
The two things you must never hand over
What a clause means. Extraction is finding and transcribing. Interpretation is deciding what an ambiguous obligation requires of you in a particular situation. The register should carry the clause's words and its location, and where the drafting is genuinely unclear it should say so and stop. A model asked "what does this mean for us" will answer, fluently, and there is no signal in its output that distinguishes a clear clause from one that a lawyer would spend an hour on.
What is missing. This is the more important one and it is much less obvious.
Language models are built to work with what is in front of them. They are structurally weak at absence — at telling you that a deed contains no unspent-funds clause at all, or that a reporting obligation you would expect for this type of funding simply isn't there. Ask a model what an agreement is missing and you will usually get a plausible list of things that agreements generally contain, which is not the same question and is not a safe answer.
Absence is a human review, done by someone who knows what this kind of agreement normally says. The register makes that review fast, because the gaps show up as empty columns across a comparable set — which is exactly why the schema has to be fixed in advance.
What you get at the end
Not a compliance artefact. A working document that answers questions you currently cannot answer quickly:
Sorted by date, it is a twelve-month obligations calendar — which tells you where the acquittal pile-ups are and lets you staff for them rather than discover them.
Sorted by funder, it is what you take into a renewal conversation, and it is the difference between negotiating from the agreement and negotiating from memory.
Read down the notification column, it tells you which events you are contractually obliged to disclose — the one thing organisations most reliably discover after the event rather than before.
Read down the survival column, it tells you what you still owe on agreements that have already ended, which is a live and generally unmanaged exposure.
It is worth saying plainly that once it exists, it has to be maintained. A register built once and left is a trap, because people trust it. Every new agreement gets extracted and verified on signing, and every variation updates the row. On a straightforward variation that is fifteen minutes or so; on a complex new deed it is longer. Either way, that is the entire ongoing cost.
How long would it take you to list every reporting obligation you're under?
If the answer involves opening more than three documents, the register doesn't exist. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations — including building the obligation register that makes the acquittal season predictable instead of surprising.
Talk to PFL →Commonwealth Grants Rules and Principles 2024 — Federal Register of Legislation
Department of Finance — Commonwealth Grants Rules and Principles 2024 now in effect
ACNC — Governance Standards
AASB — AASB 1058 Income of Not-for-Profit Entities
NDIS Quality and Safeguards Commission — NDIS Practice Standards
Comments
Post a Comment