eProcureAI / Platform / Nonprofits and grant funded

Industry

Every dollar has to go back
to the grant it came from

Grant funded organisations do not just report on spending, they have to prove which pot each cost came from. Capturing that at the request is what makes funder reporting an export rather than a rebuild.

Split at the request. Not reconstructed when a funder asks.

Grant funded purchaseRequest raised
The situation

Allocation done afterwards is allocation done badly

Grant funded organisations carry an obligation most businesses do not. It is not enough to spend money well. You have to demonstrate which grant each cost belongs to, within the period it allowed, on something it permitted.

In practice the allocation usually happens later. Finance takes a month of invoices and assigns them to programmes and grants based on supplier, date and a conversation with whoever ordered. Some of those assignments are wrong, and the errors are invisible until a funder looks closely.

The consequence is more serious than a misposted cost. A charge on the wrong grant can mean returning money, and it always means a difficult conversation with somebody whose continued funding you depend on.

The person ordering knows

They know the programme, the grant and often the split, at the moment they place the order. Capturing it there is easier for them than answering questions about it three weeks later, and considerably more accurate.

Eligibility is a date question too

Grants restrict what money can be spent on and when. Spending outside the eligible window is a common finding and entirely avoidable, because the date is known and the check is trivial once the grant is selected on the request.

How a grant purchase runs

Five steps, and the allocation never moves

Step 1

Raised against a programme and grant

Selected by the person ordering, when they are certain, rather than assigned later by somebody who was not there.

SelectedAt the request
1
Step 2

Eligibility checked

Permitted use and the grant period both compared before anybody approves, so an ineligible purchase is caught while it can still change.

CheckedPurpose and dates
2
Step 3

Split where needed

A cost serving two programmes is split at the request with the basis recorded, rather than apportioned afterwards by estimate.

BasisRecorded
3
Step 4

Committed against each grant

Balances update at approval, so a programme lead sees the real position rather than an invoiced one.

CommittedAt approval
4
Step 5

Reported to the funder

Cost by grant already allocated with backup attached, so reporting is an export.

ReportingExport, not rebuild
5
What grant funded work needs

Three things that general finance systems miss

Allocation captured at the request

The only moment anybody is certain which grant a cost belongs to is when they place the order. Everything after that is reconstruction with decreasing accuracy.

  • Programme and grant selected by the requester
  • Splits set at the request with the basis recorded
  • Carried through to order and invoice
  • No monthly allocation exercise
At the requestLive
ProgrammeSelected
GrantSelected
Split60 and 40
BasisRecorded
Allocated laterNo
CertainAt the moment of ordering

Eligibility checked on purpose and period

Two separate questions. Whether the grant permits this kind of cost, and whether the date falls inside the eligible window. Both are checked before approval.

  • Permitted use compared with what is being bought
  • Grant period checked against the date
  • Ineligible purchases routed or blocked
  • Nothing discovered during funder reporting
EligibilityLive
Permitted useCompared
Grant periodWithin window
ResultAllowed or routed
Found at reportingNothing
Two checksPurpose and dates

Funder reporting that exports

When every cost already carries its grant and its backup, reporting is a filter rather than a month of reconstruction and cross checking.

  • Cost by grant already allocated
  • Backup documents attached to each transaction
  • Funder queries answerable from the record
  • Audit evidence produced by filter
ReportingLive
Cost by grantAlready allocated
BackupAttached
QueryAnswerable
RebuildNone
ExportRather than assemble
Fund types

Four kinds of money, four sets of rules

Most organisations hold all four at once, which is exactly why capturing the fund at the request matters.

Fund typeWhat it meansWhat must be checkedConsequence of getting it wrong
UnrestrictedGeneral funds, no donor conditionsStandard budget rulesAn ordinary overspend
RestrictedGiven for a defined purposePurpose at the requestFunds may have to be returned
Grant fundedConditions and an eligible periodPurpose and datesA finding, and a difficult funder conversation
Capital appealRaised for a specific assetClassification and purposeMisreported to donors

The grant period is the check most often missed, because purpose feels like the obvious question and dates do not.

Where allocation breaks

Six failure points, all before reporting

Not captured

Ordered with no grant selected

Defaults to unrestricted and never gets recovered against the grant it should have been.

FixSelected at request
Wrong grant

Assigned from a date and supplier

A guess presented as an allocation, and usually wrong for a proportion of costs.

FixChosen by the orderer
Shared costs

One cost, two programmes

Apportioned later by estimate rather than split at the request with a recorded basis.

FixSplit upfront
Out of period

Bought outside the window

Entirely avoidable, and a common finding because dates are rarely checked.

FixPeriod checked
Missing backup

Funder asks for evidence

The supporting document is in somebody's email rather than with the transaction.

FixAttached
Overspend

Grant exhausted quietly

Invoiced reporting shows room that committed spend has already used.

FixCommitted counted
Who does what

The short version of everyone's job

Funder confidence comes from being able to answer quickly, which depends entirely on where the allocation was captured.

What people do

Select the programme and grant when ordering. That is the entire additional ask.

The human partLive
RequesterSelects programme and grant
RequesterSets the split if shared
Programme leadApproves within the grant
FinanceReports to funders
One selectionAt the moment of ordering

What eProcureAI does

Checks eligibility, carries the allocation through and keeps grant balances current.

The automatic partLive
Check permitted useAnd the period
Carry the allocationRequest to invoice
Commit against the grantAt approval
Attach the backupTo the transaction
Support reportingBy export
No monthly allocationBecause it was captured once
0programme and grant selected by the person ordering
0both checked before approval
0committed against the grant, not at invoice
0funder reporting from the record rather than a rebuild
FAQ

Questions people actually ask

How are restricted funds handled?
The grant is selected on the request and both the permitted use and the eligible period are checked before approval. An ineligible purchase is caught while it can still be changed rather than during reporting.
Can a cost be split across two grants?
Yes, at the request, with the basis for the split recorded. Splitting afterwards by estimate is where most allocation error comes from.
What stops us spending outside a grant period?
The date is checked against the eligible window when the grant is selected. It is one of the most common findings and one of the easiest to prevent.
How does this help with funder reporting?
Every cost already carries its grant and its supporting document, so reporting becomes a filter and an export rather than a month of reconstruction.
Can programme leads see their own position?
Yes. They see their own grants and programmes while finance sees the roll up, from the same underlying numbers.
What happens if a grant is nearly exhausted?
The committed position includes approved orders not yet invoiced, so the balance reflects money already promised. Alerts fire at the threshold you set.
What evidence is available if a funder queries a cost?
The transaction, who approved it and why, the grant it was charged to, and the supporting document, all held together rather than in separate places.
Do requesters need to understand grant conditions?
No. They select the programme and grant, and the system checks the conditions. That is the point of putting the check in the software rather than in a policy document.

Bring a grant and its conditions

We will configure the eligibility check on the call and run a purchase that should fail it.

Book your free demo

Related: All solutions and Budgets and Charge Codes