I start further upstream: what was planned, what arrived, whether it can be trusted and how it should connect. Each tool solves a specific problem. The architecture explains how those pieces can support the same decision.
Portfolio demonstration · invented data · local Python and Excel tools. The invoice connection below is a proposed extension; the tools are not presented as one deployed platform.
Select a component to see its role, what it produces and what must be checked before it moves forward.
Solid flow: reporting architecture described in the existing explainer. Dashed finance branch: an integration design, subject to agreement on matching rules.
These examples translate the existing PowerPoint’s source → controls → decisions story into an explorable portfolio walkthrough.
Capture the intended investment, flight dates and allocations. Keep plan versions and monthly approvals so a later revision does not silently rewrite an earlier reporting period.
Architecture decision: state and creative allocations are children of a budget, not additional spend.
Explore a planning example ↓Check CSV and Excel submissions against versioned schemas. Report source rows, original values, rule severity and file fingerprints in Excel, CSV and JSON outputs.
Architecture decision: flags support review. Similar dimensions alone do not prove that records are duplicates.
Run a synthetic check ↓A standalone dashboard turns validated snapshots into linked pacing and performance views. Shared date controls and filters help users investigate the same reporting window.
Architecture decision: missing actuals remain unknown; forecasts need approved plans and sufficient coverage.
Try the original date-range demo ↗Track expected and received invoices, replace estimates with actual values and link multiple payments to an invoice. Keep manual payment status and available credits visible.
Architecture decision: planned budget, delivered spend, billed amount and cash paid are different measures.
Explore the finance branch ↓A small browser illustration of checks in the local validation tool. The Python package supports broader schema and file checks. This demonstration uses fixed synthetic records and never modifies a source file.
| Source row | Activity date | Campaign start | Platform | Spend |
|---|
| Row | Field | Original value | Severity | Finding / next step |
|---|
Blocking failures exclude a file from reporting. Warnings request review. The existing checker is read-only: it does not rename headers, correct values or automatically delete potential duplicates.
Synthetic 10-day example: approved target R10,000, reported spend R8,000. A draft plan is ineligible for pacing. Complete reporting is needed to interpret variance; a lower reported total with missing files is not proof of underspend.
The invoice tracker adds a different operational view: what is expected, what has arrived, what is outstanding and what needs follow-up. A future reconciliation could compare these records with delivery after agreeing on scope, fees, currency and period.
Schedule + manual overrides
One invoice, one balance
Invoice ID links each payment
Synthetic invoice: estimated R10,000, actual R9,000. Available credit R500 is displayed separately and is not automatically allocated. The workbook’s payment status is manually selected; this example shows arithmetic, not a payment action.
R8,000 in reported media spend and an invoice for R9,000 do not establish an error. Fees, tax, billing periods and adjustments may explain it. Agree those definitions before flagging a financial discrepancy.
Keep originals, inspect the file contract and surface blocking issues with row-level evidence. Human review resolves ambiguity.
Use approved plan snapshots and compatible keys. Keep delivery, outcomes and invoices at their own level of detail to avoid multiplying totals.
Generate a dated reporting snapshot. Declare the cutoff, coverage, currency and spend basis. Review the stakeholder scope before export.
I think about the handoffs between tools: which input is authoritative, which checks belong at each step, how versions are preserved and what evidence is needed before a number becomes a recommendation.
These are built tools and synthetic demonstrations. They support the approach; they do not establish production adoption or measured savings. The employment reporting result is documented separately.
Read the measured reporting case ↗We can map the inputs, checks, owners and decisions, then agree which part is worth fixing first.
Discuss your reporting system ↗