Liberia's national budget is public. By law, it has to be. Every year the Ministry of Finance publishes it as a PDF on their website, hundreds of pages of line-item spending across 117 government ministries and agencies, six years of historical and projected figures per entity.
Nobody reads it. Not because nobody cares, but because a 625-page PDF with no table of structured data is functionally a write-only document. A journalist trying to track one ministry's spending has to manually find the right page, copy numbers into a spreadsheet, and repeat that 117 times across multiple fiscal years. A World Bank analyst comparing procurement patterns across ministries does the same thing, slower, with less institutional memory of where things are buried.
I built FiscalTrace to fix that. It's a small pipeline: extract, structure, compute variance, serve through an API. Five stages, no ML in the extraction step, nothing exotic. The interesting part isn't the architecture, it's what falls out the other end once government financial data actually becomes queryable.
What it found, automatically, on the first run:
The Ministry of Agriculture's budget jumped 262% between FY2023 actual spending and the FY2025 approved budget, from $3.7M to $13.4M. A program serving vulnerable communities had its budget cut 74% over the same window, from $7.8M to $2.0M.
Neither of those numbers required me to know what I was looking for. They came out of a generic "flag anything that moved more than 20%" rule running against the structured table. That's the whole point, the system doesn't need a human to know where to look first.
The extraction problem
pdfplumber handles the actual PDF parsing, but the budget document isn't a clean table you can extract_table() your way through. It's six years of data per ministry, laid out across multiple pages, with section headers, footnotes, and inconsistent column spacing that breaks naive table detection about a third of the time.
What worked was pattern matching against the structural regularities that do hold, every ministry entry follows the same line-item format regardless of which page it's on. I extract per-page, then stitch entities together by matching on the entity code, which is the only consistently formatted field across the entire document.
python# simplified — the real extractor handles edge cases around

multi-line entity names and footnote markers

def extract_entity_row(line, page_num):
match = ENTITY_ROW_PATTERN.match(line)
if not match:
return None
return {
"entity_code": match.group("code"),
"entity_name": match.group("name").strip(),
"fy23_actual": parse_currency(match.group("fy23")),
"fy24_budget": parse_currency(match.group("fy24")),
"fy25_budget": parse_currency(match.group("fy25")),
"source_page": page_num,
}
Full extraction of all 117 entities across 6 fiscal years runs in under 4 seconds. The slow part was never the parsing, it was figuring out which regex actually generalizes across a document that wasn't designed to be machine-read.
Variance, computed once, not on every request
Once the data lands in Postgres, I compute budget growth percentage and execution rate at ingest time, not at query time. This matters more than it sounds like it should, anomaly detection on a 117-row table is cheap either way, but computing it once means the /api/v1/anomalies endpoint is just a WHERE abs(growth_pct) > threshold query against a precomputed column. No runtime aggregation, sub-millisecond response.
sqlALTER TABLE spending_entities
ADD COLUMN growth_pct NUMERIC GENERATED ALWAYS AS (
CASE WHEN fy23_actual > 0
THEN ROUND(((fy25_budget - fy23_actual) / fy23_actual) * 100, 1)
ELSE NULL
END
) STORED;
What's live right now
Eight endpoints, fully public, no auth required except the bulk variance export:
GET /api/v1/overview national summary, total budget, entity count
GET /api/v1/sectors budget by sector, all 11
GET /api/v1/entities full list, sortable, filterable
GET /api/v1/entities/{code} single ministry detail
GET /api/v1/search full-text search by entity name
GET /api/v1/anomalies the interesting part
bashcurl "https://fiscaltrace.ericdiamason.tech/api/v1/anomalies?threshold_pct=20"
json{
"entity_name": "MINISTRY OF AGRICULTURE",
"fy2023_actual": 3704312,
"fy2025_budget": 13432776,
"change_pct": 262.6,
"alert_type": "large_increase"
}
What I'd do differently
The extraction regex is brittle in a way I'm not fully comfortable with. It works on this specific document's formatting, and I haven't tested it against a different country's budget PDF yet, which is the actual interesting next step, does the same pattern-matching approach generalize, or does every government format their budget just differently enough to break it.
The anomaly threshold (20%) is a number I picked, not one I derived. It's a reasonable starting heuristic, but it's not informed by any historical baseline of what "normal" year-over-year ministry budget volatility looks like in Liberia specifically.
It's open source: github.com/ericdiamason/fiscaltrace

Live: fiscaltrace.ericdiamason.tech
Happy to talk through the extraction approach or the schema design in the comments.