The request, and what it really is
It arrives as an email. A verification visit next month, or a spot check on the last claim, or a query about one figure — and could you provide the supporting documents.
What is being asked is simple: show me that this figure corresponds to something real. Not whether your bookkeeping is sound, not whether the programme succeeded. Just: here is a number you gave us; what is it made of?
For an organisation that captured documents as it went, that is an afternoon. For one that did not, it is a fortnight of archaeology, conducted under a deadline, by someone who was often not there when the money was spent.
The difference between those two is not diligence. It is one decision made months earlier about when documents get collected.
The three-part standard
Funders word this differently and mean the same thing. Every claimed cost should be able to show three things.
What was bought — an invoice or receipt showing the supplier, the date, the amount and what it was for.
That it was paid — a bank line, a card statement entry or a remittance, tying back to the same amount.
Why it belongs to this grant — obvious for most costs, and needing a recorded note for anything shared, apportioned or unusual.
The first two are the pair that gets separated. Organisations tend to have one or the other in easy reach — the accounting system holds the payments, a folder somewhere holds the invoices — and connecting a specific payment to a specific document is the work.
The third is the one that decays. Why a cost belonged to a grant is obvious at the time and gone within months. It costs one line to record and cannot be reconstructed once the person who knew has moved on.
What counts as evidence, by cost type
| Cost | Usually expected | Where it goes wrong |
|---|---|---|
| Supplier invoice | Invoice plus proof of payment | Payment never linked to the document |
| Small purchase | Receipt, legible | Faded, lost, or never handed over |
| Freelance work | Invoice plus the agreement or brief | No written scope to point at |
| Travel | Receipt plus the reason for the journey | Reason recorded nowhere |
| Equipment | Invoice, quotes if above a threshold | Quotes not kept |
| Shared cost | Document plus the allocation basis | Basis was a judgement nobody wrote down |
| Room or venue | Invoice plus what it was used for | Booking confirmation only |
Read the right-hand column as a list. Almost every entry is something that would have taken ten seconds at the time and cannot be fixed afterwards at any price.
The equipment row is worth singling out. Where an agreement requires competitive quotes above a threshold, the quotes are part of the evidence and they are routinely deleted once the order is placed. Nothing about the invoice reveals that they ever existed.
Why assembling it later costs so much more
The intuition is that a pack is the same work whenever you do it, just displaced. It is not, and the difference is much larger than most people estimate.
Collected as costs arrive, one document takes about thirty seconds: it is already in front of you, you know what it was for, and it goes to one place.
Collected nine months later, the same document takes between two minutes and an afternoon. You are searching several places, you are working out what it was for from the supplier name, and roughly one in ten will not be found at all.
That last fraction is the real cost. A document that cannot be produced is a cost that may have to be withdrawn from a claim — money you spent legitimately and cannot keep, because the paper is gone.
There is a compounding effect too. The people who could explain an unusual cost are the ones most likely to have left, and their explanation is exactly the part that no filing system captures on its own.
Samples, full packs, and why coverage beats polish
Most verification works on a sample. A funder picks a number of lines — sometimes the largest, sometimes at random, sometimes the ones that looked interesting — and asks for those.
That has a direct practical consequence: you cannot prepare selectively. Since you do not know which lines will be chosen, the only workable approach is that every line can be evidenced.
It also means presentation matters less than people think. A neatly bound pack covering the items you expected to be asked about is worth less than a plain folder where anything can be found. Coverage first, polish second.
Occasionally a full pack is requested — commonly at a final claim or where something earlier raised a question. That is where continuous collection pays for itself completely, because a full pack assembled from scratch across a multi-year programme is a project rather than a task.
One useful habit: after each claim, pick three lines yourself and try to evidence them as if asked. Fifteen minutes, and it tells you whether your coverage is real while there is still time to do something about it.
Ordering it so it can actually be checked
The person checking has a schedule in front of them and wants to get from a row to its documents without asking you. Every extra step is a question, and questions cost days.
Three conventions do almost all the work. Give each claim line a reference and put that reference on the file. Order the files as the schedule is ordered, so following it is sequential. Keep the invoice and its payment proof together rather than in separate piles organised by type.
That last one goes against instinct. Filing by document type feels tidy and it makes verification twice the work, because the checker has to cross-reference between two sets to establish one fact.
Where this becomes almost free is when the rows already carry their source. If each extracted row holds the file and page it came from, assembling a pack in schedule order is a matter of following references rather than a filing exercise.
Add a short covering note: what period, what is included, and anything you already know is missing or unusual. Two paragraphs, and it changes the reading from investigation to confirmation.
What not to send
A pack should contain what is needed and no more, and the boundary is less obvious than it looks.
Redact personal data the funder does not need. Beneficiary names on a room booking, staff bank details, anything about individuals that has no bearing on whether a cost was incurred.
Do not redact the substance. Prices, supplier names, quantities and descriptions are the thing being verified. Blacking those out defeats the purpose and, reasonably enough, invites a closer look.
Do not send more than was asked for. Volunteering a whole quarter when three lines were queried is not helpfulness; it creates work for the checker and expands the scope of the conversation.
Do not send unrelated commercial detail.An invoice covering both funded and unfunded work needs the funded lines and an explanation of the split, not necessarily every other client’s pricing on the same document.
Where a redaction is made, say that it was made and why. A silently altered document is a much bigger problem than a marked redaction with a one-line reason next to it.
What actually makes a pack fail
Rarely fraud. Almost always one of these five, in roughly this order of frequency.
| Problem | What the checker sees | Preventable by |
|---|---|---|
| Document missing | A figure with nothing behind it | Capture at the time |
| Payment not linked | An invoice, unproven | Keeping the pair together |
| Amount does not match | Part-payment or a credit note | A note explaining the difference |
| Allocation unexplained | 60% of an invoice, no reason | Recording the basis in words |
| Illegible receipt | A grey rectangle | Photographing when new |
The third row is worth dwelling on because it is the one that looks worst and is usually innocent. An invoice for £1,200 against a claimed £900 is a part-payment, a credit note or a split — all perfectly ordinary, all alarming without a sentence of explanation attached.
And when something genuinely is missing, disclose it. “We cannot locate this receipt; here is the payment and the order confirmation” is a routine conversation. The same gap discovered by the checker is an entirely different one.
Building it as you go
The whole argument of this page reduces to one operational change: the pack is assembled continuously, not on request.
In practice that is a weekly or fortnightly pass over whatever documents have arrived. Extract them, let each row keep the file and page it came from, note anything shared or unusual while it is still fresh, and move on.
Batch processing is what makes the habit survivable — a hundred files in one operation rather than one at a time, so the routine costs minutes rather than an afternoon. The mechanics are on merging documents into one export.
What you have at the end of a period is not a pile to be worked through but a table where every row already points at its evidence. Producing a pack from that is filtering, not archaeology.
And the same table is what the claim itself is built from, which is the real economy here — the evidence work and the reporting work are the same work done once. The claim side is on drawdown reporting.
How long to keep it
Longer than you think, and longer than your ordinary retention policy. Grant agreements frequently require records to be kept for a number of years after the programme ends, which can be well beyond what you would keep for tax.
Two things follow. Check the requirement at the start rather than at the first clear-out, and make sure the retention applies to the documents themselves rather than only to the accounting entries.
The second point catches people out during system migrations. An accounting system change carries the transactions and frequently leaves the attachments behind, and nobody notices until a verification request arrives two years later.
Keeping an exported table with the documents alongside it — outside whichever system you happen to use — is cheap insurance against exactly that. A folder and a spreadsheet outlive most software decisions.
Who holds what, and why that is the real problem
An evidence pack is usually assembled by someone in finance. Most of the material it needs was generated by someone else entirely, and that split is the root of nearly every gap.
| Held by | What they have | What is lost |
|---|---|---|
| Finance | Payments, the ledger, the claim | What each cost was actually for |
| Delivery staff | Receipts, context, the reason | Nothing, until they leave |
| Whoever ordered it | Quotes, the brief, the approval | Deleted once the order is placed |
| Suppliers | A copy of the invoice | Only recoverable if you ask in time |
The second row carries the most and loses it fastest. Context has a shelf life measured in weeks, and nothing in a filing system captures it — a receipt for £80 of materials tells you the amount and never tells you which session it was for.
The fourth row is the useful escape hatch people forget. Where a document is genuinely lost, the supplier usually still has it, and they will send a copy if asked within a reasonable time. That option closes as suppliers change systems or go out of business, which is another argument for finding gaps early rather than at a verification visit.
Six mistakes
Waiting for the request
A pack assembled nine months later costs many times more per document, and about one in ten is never found.
Filing by document type
Invoices in one pile and payments in another doubles the checker's work and generates questions.
Not recording why a cost belonged to the grant
Obvious at the time, gone in months, and impossible to reconstruct once the person has moved on.
Deleting quotes once an order is placed
Where a threshold requires them, they are part of the evidence and nothing on the invoice reveals they existed.
Redacting the substance
Blacking out prices and suppliers removes the thing being verified and invites a closer look.
Assuming migration carries attachments
System changes move transactions and leave documents behind. Verification arrives years later.
What this is not
Not a document management system
It reads documents into rows that reference their source. Where the files live is your decision and your storage.
Not a record of what a cost was for
That comes from the person who spent the money, at the time. Software carries the answer; it cannot supply it.
Not a substitute for the original
Extracted rows are a working layer. The document itself is what a funder asks to see, and your retention obligation applies to it.
Not an audit opinion
Nothing here says a claim is correct. It makes the underlying material findable, which is a precondition rather than a conclusion.