Correct, coded, and still not claimable
The invoice is real. The amount is right. It is coded to the funded programme, and the programme genuinely incurred it. And it cannot go in the claim, because the agreement excludes that category of spend, or because it falls two days outside the window, or because it takes a heading past its cap.
None of that is discoverable from the document. It comes from a contract someone signed, usually months earlier, often not by the person now preparing the claim.
Which is why eligibility errors survive every other check. Bookkeeping catches wrong numbers. Coding catches wrong categories. Neither has any view on a condition that lives in a PDF in a shared drive.
Screening closes that gap by turning the conditions into rules and running them over every row, every time — so the check happens whether or not the person doing this quarter’s claim has read the agreement.
Not the same thing as validation
These two get conflated constantly, and keeping them apart is what makes either useful.
| Validation | Eligibility screening | |
|---|---|---|
| Question asked | Is this data right? | Is this cost claimable? |
| Source of truth | The document itself | A contract |
| Same for everyone | Yes | No — differs per grant |
| Typical finding | Lines don't sum to the total | Category excluded by the agreement |
| Can it be automatic | Largely | Only the mechanical part |
| Consequence of missing it | A wrong figure | A repayment |
Both run, and they run in that order: there is no point screening a figure that was misread. The arithmetic side is described on the validation engine; this page is only about the second column.
The last row is why screening is worth building deliberately. A wrong figure gets corrected. An ineligible cost that reaches a claim and is found later is money you have to give back, usually along with a broader look at everything else you submitted.
Six kinds of rule
Almost every funder condition that can be checked mechanically falls into one of these. The ones that do not are judgements, and they are dealt with further down.
| Rule | Checks | Catches |
|---|---|---|
| Date window | The date is inside the period | Costs before the start or after the end |
| Excluded category | The cost type is permitted | Entertainment, fines, interest |
| Heading cap | The heading has room left | A heading quietly overspent |
| Item threshold | Items above a limit have what they need | Equipment bought without quotes |
| Supplier restriction | The supplier is permitted | Related parties, barred suppliers |
| Already claimed | This document appears once | The same cost against two funders |
Two of these — the first and the last — account for most of what actually gets caught in practice. The middle four matter more per instance and fire less often.
The date window
The simplest rule to state and the one that produces the most work, because a cost has more than one date and the agreement usually names only one of them.
A rule therefore has two parts: which date counts, and what the window is. The first is the part people skip, and skipping it means the convention drifts between quarters — which is worse than choosing the less convenient date.
Beyond the hard edges there is a soft zone worth treating separately. Anything within, say, a week of either boundary gets flagged regardless of which side it fell on, because that is where a defensible decision and an indefensible one look identical in a spreadsheet.
There is a second window most people forget: the grant period as a whole, distinct from the claim period. A cost can be inside the overall programme and outside this quarter — that is a timing question with an ordinary answer. A cost outside the programme entirely is a different problem and should not be flagged the same way.
Excluded categories, and why they are harder than they look
Most agreements list things that cannot be claimed. The lists rhyme across funders — entertainment, alcohol, fines and penalties, interest, gifts, some kinds of marketing — without being identical.
The difficulty is not the list. It is that a document rarely announces which category it belongs to. A restaurant invoice might be a team celebration, a working meeting with a partner organisation, or catering for a funded event. Same supplier, same amount, three different answers.
Screening therefore works on signals rather than certainty: the supplier, the line descriptions, past decisions about the same supplier. What it produces is a shortlist for a person, not a ruling.
What makes this workable over time is recording the decision alongside the supplier. The second restaurant invoice from the same place, in the same circumstances, does not need to be reasoned about from scratch — and the rules accumulate rather than the questions.
One caution worth stating plainly: exclusion lists are where over-eager automation does real damage. A rule that quietly removes every cost from a category will eventually remove a legitimate one, and nobody will ever notice, because a missing row raises no question.
Caps, thresholds and the running total
A heading cap is different from every other rule here, because whether a cost breaches it depends on what else has already been claimed.
That makes it a running check rather than a per-row one. The hundredth pound of travel is fine and the ten thousand and first is not, and which row happens to cross the line is arbitrary.
The useful behaviour is not to flag the row that crossed the cap. It is to show the heading approaching it, with enough warning to do something — move a cost, request a virement, or stop spending against it. A cap breach discovered at claim time is already a problem; the same information a month earlier is a decision.
Item thresholds work differently. Above a stated amount an agreement often requires something extra — competitive quotes, prior approval, an asset register entry. The check is mechanical and the follow-up is not, so the flag says what is missing rather than that the cost is barred.
Both benefit from being visible continuously rather than at claim time. A cap you look at once a quarter is a cap you find out about too late.
The same cost claimed twice
The most serious thing in this area, and the least likely to be caught by anything else, because both claims look completely correct in isolation.
It happens without anyone intending it. Two programmes, two people preparing two claims from the same folder of invoices, no shared record of what went where. Each does their job properly and the same invoice is claimed in full, twice.
The check is straightforward once all allocations live in one place: has this document, or this line, been allocated to more than one programme, and do the allocated shares sum to more than the document? Both conditions are computable and neither is a judgement.
What is a judgement is the answer. The same document appearing twice is often perfectly legitimate — a genuine split across two programmes is exactly how shared costs should be handled. The flag distinguishes “this appears more than once” from “this is wrong”, and only a person can do the second part. How the splitting itself works is on dimension tagging.
A flag is a question, not a verdict
This is the design decision that everything else follows from, so it is worth being explicit about.
Nothing is removed. A row that fails a rule stays in the table, marked, with the rule it failed named next to it. You can then include it, exclude it, or go and ask — and whichever you choose is recorded.
The alternative — silently dropping what fails — is attractive because it produces a clean-looking claim with no effort. It is also how legitimate costs get lost permanently. A row that disappears generates no question, and money you were entitled to and did not claim is invisible in every direction.
It also matters for the person who certifies. Signing a claim means being able to say what is in it and what was left out and why. A process that removes things without saying so makes that impossible, however accurate it happens to be.
So the output of screening is a shorter list to think about, not a decision already made. On a normal quarter that list is a small fraction of the rows, and the rest needs no attention at all.
Writing the rules down
Someone reads the agreement once and turns the conditions into rules. That is a deliberate boundary: an agreement contains language that needs interpreting, and interpretation is not a job to hand to software.
What makes the exercise quick is knowing what to look for. Four sections carry almost everything: the period, the budget table, the eligible and ineligible cost lists, and the procurement or approval thresholds.
Record each rule with three things — what it checks, where it came from, and when it was decided. The middle one is what lets a successor understand a rule they did not write. The third is what lets you defend a claim prepared before a funder later clarified something.
Expect the rule set to grow for two quarters and then stabilise. Most of the additions come from questions the funder answers, and each answer is worth capturing as a rule rather than as a memory — that is how the knowledge survives someone leaving.
Keep one rule set per programme. It is tempting to maintain a single organisation-wide list, and it goes wrong the first time two agreements disagree — which they do more often than not.
What review actually looks like
In a normal quarter, on a few hundred rows, screening puts a handful in front of a person. Here is what happens to them.
| Flag | Usual outcome | Time |
|---|---|---|
| Near the date boundary | Included, on the stated convention | Seconds |
| Category needs a look | Included with a note, or moved | A minute |
| Above a threshold | Included once the paperwork is found | Longer |
| Heading near its cap | A conversation, not a row decision | Separate |
| Appears against two programmes | Split confirmed, or corrected | A few minutes |
Note that most outcomes are “included”. That is the expected result and not a sign the rules are too loose — the value is in having looked, and in the record that you looked.
If a large share of rows is being flagged, the rule set is miscalibrated rather than the spending being wrong, and the fix is to tighten the rules rather than to start ignoring the flags. A screening pass everyone has learned to click through is worse than none.
Starting from nothing
A blank rule set is intimidating, and the instinct is to sit down with the agreement and try to encode all of it at once. That produces a large rule set nobody trusts and several rules that turn out to be wrong.
Week one: two rules. The date window and a short list of obviously excluded categories. Between them these catch the majority of what will ever be caught, and both are unambiguous enough that nobody will argue with a flag.
Month two: add what the first pass found. Every flag that turned out to be a real question is a rule waiting to be written. Every flag that turned out to be noise is a rule that needs narrowing.
Month three onwards: add what the funder tells you. Clarifications arrive over the life of a grant, usually in email replies. Each one is worth converting into a rule immediately, because that is how the knowledge survives the person who asked the question.
Expect the set to stabilise after two quarters. If it is still growing quickly in year two, something in the agreement was never properly read — or the rules are being written to describe individual costs rather than categories of cost, which is a different problem and produces a set nobody can maintain.
One test of a healthy rule set: could someone who has never seen the agreement apply it, and would they get the same answers you do? If not, the rules are still carrying assumptions that live in your head.
What it will not do
It does not know your agreement
No access, no built-in funder library. Someone reads the contract and writes the rules; that is the whole design.
It does not rule on eligibility
It applies your rules and shows what fails them. Whether a cost is genuinely allowable is a judgement, sometimes one for your funder.
It does not remove anything
Flagged rows stay in the table with the rule named. Silent removal produces clean claims and lost entitlement.
It does not read intent
Whether a meal was a funded event or a team celebration is not in the document. Screening narrows it to a shortlist; a person answers it.
It does not replace your funder relationship
The cheapest way to resolve an ambiguous condition is to ask. A rule written after asking is worth more than one written after guessing.