Subrecipient Monitoring Software: How Pass Through Entities Prove They Actually Watched the Money

Why pass through monitoring falls apart past a dozen subrecipients

You are the grants compliance director at a state agency, a large city, or a nonprofit intermediary. Federal money lands in your accounts and leaves again as subawards to community organisations, county departments, school districts and small nonprofits that have three staff and a bookkeeper who works Thursdays. Under 2 CFR 200.332 you are the pass through entity, which means the federal awarding agency does not chase your subrecipients. It chases you. If a subrecipient charges an unallowable cost, you repay it. If your monitoring was inadequate, the finding is against your organisation, not theirs.

The operational picture is almost always the same. Risk assessment happens once a year in a spreadsheet that scores each subrecipient on prior experience, audit history and dollar value, using weights that made sense to the analyst who built it in 2019 and have never been documented. Subaward agreements are Word templates with the terms and conditions pasted in. Reimbursement requests arrive as emailed PDFs with a scanned general ledger detail behind them, get reviewed by whoever is free, and get approved in an email thread that lives in one person's Outlook. Single audit reports arrive as attachments, sit in a shared drive folder organised by year, and the corrective actions in them are read once and never followed up.

None of that is negligence. It is what happens when the volume grows past what a filing convention can hold. The failure mode is specific: when a federal monitor or your own external auditor asks you to demonstrate that monitoring occurred at the frequency your own risk assessment called for, you cannot produce it as a record. You can produce evidence that work happened. You cannot produce evidence that the work happened on schedule, in a consistent order, against a documented standard. That distinction is the entire finding.

What AmpliFund and eCivis actually do, and where they stop

Both are real products with real customers and you should look at them before you talk to anyone about a build. AmpliFund handles the grant lifecycle well on the recipient side and has genuine subaward capability. eCivis has long roots in state and local grants management and knows public sector procurement. Neither is a bad product.

Where they stop is the same place most grant tools stop, because they were architected around the applicant journey. The centre of gravity is your own award: the application, the budget, the drawdown, your reporting to the federal agency. Monitoring downstream recipients is a module hung off the side of that model. So the risk assessment is a form with fields rather than a scoring engine you control. The monitoring calendar is a set of tasks rather than a rule that says a high risk subrecipient on a construction program gets a desk review every quarter and an onsite visit annually, and that the clock starts on the date of the subaward not the date somebody remembered. Reimbursement review is document upload and approval, not line level cost testing against the approved budget with a sampling rule that varies by risk tier.

The other gap is your own systems. Your subaward obligations sit in your ERP (Enterprise Resource Planning), whether that is Workday, Tyler Munis, Oracle or a state accounting system nobody has fully documented. Payment happens there. If your monitoring tool does not know what has actually been disbursed against each subaward, your monitoring is running on a copy of the numbers, and copies drift.

Problem one: a risk assessment nobody can reproduce

Uniform Guidance requires you to evaluate each subrecipient's risk of noncompliance and to calibrate monitoring to that risk. It deliberately does not tell you how. So every pass through entity invents a scoring model, and the model is where the exposure sits. If you cannot show why a subrecipient scored medium instead of high, you cannot defend the monitoring level that followed from it.

A custom build turns the model into a versioned object. Each risk factor is a named rule with a weight and a data source: prior single audit findings, whether the subrecipient has expended federal awards above the Single Audit threshold, which moved to $1 million under the 2024 Uniform Guidance revisions, months since the last onsite visit, percentage of the subaward drawn in the final 30 days of a period, staff turnover in the finance role, late reports. Scores recompute when the inputs change rather than once a year. Critically, the model is versioned, so when an auditor asks how a 2025 score was produced you replay the 2025 model rather than the current one. That single design decision has saved more monitoring programs than any dashboard.

Problem two: reimbursement review is a PDF slog with no sampling logic

The subrecipient emails a request for $84,000 with a ledger export and 40 receipts. Your reviewer opens each PDF, checks a few against the approved budget line, looks for anything obviously unallowable, and approves. There is no record of which transactions were tested, so next quarter someone tests a different sample and nobody knows the coverage.

What the build must do is make the test itself a record. Reimbursement requests come in as structured lines mapped to approved budget categories, not as an attachment. The system flags variance against the approved budget, cost categories that require prior written approval, costs incurred outside the period of performance, and indirect charged above the negotiated rate or above the de minimis rate, which the 2024 revisions raised to 15 percent of modified total direct costs. Sampling is a rule: high risk subrecipients get every transaction above a threshold tested plus a random draw, low risk get a smaller draw. Each tested item carries the reviewer, the date, the conclusion and the document. When the auditor pulls a request from 14 months ago, the test work comes with it.

Document extraction is the one place machine learning earns its budget here. Subrecipient ledgers and receipts arrive in every format a small nonprofit can produce. An extraction pass that reads a scanned invoice into vendor, date, amount and description, then matches it to the claimed line, removes the transcription work while leaving the judgement with your reviewer. It is not an approval engine and you should refuse to build it as one.

Problem three: single audits and corrective actions that go nowhere

Audit reports are due to the Federal Audit Clearinghouse within nine months of the subrecipient's fiscal year end. Your job is to know which subrecipients were required to have one, to obtain it, to read the findings that relate to your funds, to issue a management decision, and to track the corrective action to completion. Most pass through entities do the first three and stop.

A build makes this a tracked object rather than a folder. Each subrecipient gets an expected audit status derived from their expenditure level. Overdue audits generate escalation. Findings are entered as records with a management decision deadline, an assigned owner and a corrective action plan with milestone dates. The subrecipient uploads evidence of remediation through a portal against the specific milestone. When the finding recurs the following year, the system already knows, and your risk score moves without anyone remembering to move it.

What a custom build must include

The non negotiable pieces: a subrecipient register with entity identifiers, the assurances and certifications on file, and an active check against the federal exclusions list before every subaward and before every payment. Subaward issuance from a clause library, so the terms and conditions that flow down are the ones the specific federal program requires rather than whatever was in the last Word file. FFATA subaward reporting for awards at or above the $30,000 threshold, generated from the subaward record instead of re keyed. A monitoring calendar driven by the risk model. Desk review and onsite visit templates with structured findings. A subrecipient facing portal, because chasing documents by email is where your staff time actually goes. And a write back to your financial system so obligations, disbursements and available balance are one number, not three.

Retention matters more here than in most builds. Uniform Guidance record retention is generally three years from submission of the final expenditure report, longer if litigation or audit is open. Your system needs a legal hold concept and an export that produces a defensible evidence pack per subaward, because the thing you are really building is the ability to answer a monitor in a day rather than a month.

Cost, timeline and what moves the price

In Digital Heroes delivery experience, a first release covering the register, risk model, subaward issuance and reimbursement review with structured testing runs $70,000 to $150,000 and ships in 12 to 18 weeks. Adding single audit tracking, corrective action follow up, site visit workflows, FFATA generation, the subrecipient portal and financial system integration takes the program to $180,000 to $400,000 over 8 to 14 months.

What pushes the number up: the number of distinct federal programs you pass through, because each brings its own flow down terms, reporting cadence and allowable cost quirks. Integration with a state accounting system, which is usually the longest pole and is rarely a documented API. Public sector security review, accessibility conformance to Section 508 for anything a subrecipient touches, and procurement timelines that add months before a line of code exists. What keeps it down: starting with your two largest programs and the subrecipients that carry the most dollars, then extending.

When buying is the right answer

Buy if you run one federal program with under ten subawards, uniform reporting, and a compliance officer who can hold the whole picture. Buy if your organisation cannot commit a product owner for a day a week, because a monitoring build without an internal owner turns into a form nobody fills in. AmpliFund and eCivis both cost far less than a build and both are better than the spreadsheet you have now.

Build when the risk model is genuinely yours and needs to be defensible, when you pass through to 25 or more subrecipients across multiple programs, when your subrecipients are small organisations who will never adapt to a vendor's fixed workflow, or when you have already taken a monitoring finding. The trigger is not volume alone. It is the moment the answer to how do you know monitoring happened has to be a system rather than a person.

How to choose a developer for this

Ask them to explain the difference between a subrecipient and a contractor under 2 CFR 200.331 before you discuss features. If they cannot, they will build you a vendor management tool and you will discover the gap during your next single audit. Ask how they would version the risk model, and listen for whether they understand that historical scores must be reproducible. Ask what they have integrated with on the finance side and get the specific system name, because Tyler, Workday and a bespoke state ledger are three different projects. Ask how they handle evidence retention and legal hold. And settle code and data ownership in writing before kickoff: you should hold the repository, the cloud accounts and the right to bring in anyone else. At Digital Heroes the client owns the code from the first commit, and any developer who resists that is selling you a dependency rather than a system.