The Validation Playbook: 12 Controls Every Finance Team Should Run

Every finance team reconciles. Few validate.

Reconciliation happens at month-end — you compare two datasets and investigate the differences. Validation happens at the point of entry — you reject bad data before it reaches the general ledger. One is reactive. The other is preventive. Most mid-market finance teams rely almost entirely on reconciliation, then wonder why the close takes 10-15 days.

This is the playbook we use. Twelve specific controls, organised by when they fire and what they catch. Not governance theory. Not a maturity model. The actual checks.

The three layers

Before the specific rules, the framework. Every data control falls into one of three categories:

Preventive controls stop bad data from entering the system. They fire at the point of entry — when a journal is posted, when an invoice is recorded, when a transaction is imported. If the data doesn’t meet the rule, it gets rejected.

Detective controls find problems that made it past prevention. They run on a schedule — daily, weekly, or as part of the close process. They flag anomalies, inconsistencies, and breaks.

Corrective controls fix what detection finds. They define the workflow: who investigates, how the fix is documented, how you prevent recurrence.

Most finance teams have detective controls (the month-end reconciliation) and corrective controls (manual journal entries). Almost none have preventive controls. That’s where the biggest gains are.

Preventive controls (stop bad data at the door)

1. Chart of accounts validation

What it checks: Every transaction is posted to a valid, active account code. No orphan codes. No deprecated accounts still receiving entries.

Why it matters: A chart of accounts that hasn’t been reviewed in three years will have duplicate accounts, accounts nobody uses, and accounts that should have been closed after a restructure. Transactions posted to wrong accounts don’t get caught until someone asks “why is this margin number different from last month?”

How to implement: Maintain a master CoA with status flags (active, frozen, deprecated). Block posting to any account not flagged active. Review quarterly — not annually.

What it catches: Misclassified expenses, revenue posted to wrong entities, cost centres that no longer exist.

2. Mandatory field enforcement

What it checks: Every transaction has the minimum required attributes before it’s accepted — cost centre, project code, currency, counterparty, description.

Why it matters: Incomplete transactions create downstream problems. A cost entry without a cost centre can’t be allocated. A revenue entry without a customer code can’t be analysed by segment. The accountant knows what it means today. Nobody will know in six months.

How to implement: Define the minimum field set per transaction type. Configure your ERP or data layer to reject entries missing required fields. This is a system setting in most ERPs — it’s just rarely turned on.

What it catches: Unallocated costs, unattributable revenue, transactions that can’t be consolidated or reported by dimension.

3. Range and reasonableness checks

What it checks: Values fall within expected boundaries. A single invoice for EUR 2 million when the average is EUR 20,000 gets flagged. A negative revenue entry gets blocked. A salary payment 10x the normal range triggers a hold.

Why it matters: Typos and decimal errors are the most common data quality failure at mid-market. A misplaced decimal turns a EUR 5,000 expense into EUR 50,000. It’s obvious in hindsight. It’s invisible in a batch of 2,000 transactions.

How to implement: Set tolerance thresholds per transaction type based on historical patterns. Flag anything outside plus or minus 2 standard deviations for review. The thresholds don’t need to be perfect — they need to exist.

What it catches: Decimal errors, duplicate entries, posting to wrong currencies, one-off entries that distort period results.

4. Duplicate detection at entry

What it checks: The same transaction isn’t recorded twice. Same vendor, same amount, same date, same reference — flagged before posting.

Why it matters: Duplicate invoices are the most expensive data quality failure in accounts payable. Hackett Group data shows top-quartile organisations catch duplicates at entry; bottom-quartile catch them (maybe) at audit.

How to implement: Hash key fields (vendor + amount + date + reference) and check against the last 90 days of transactions. Match on combination, not individual fields — same amount from same vendor on different dates might be legitimate.

What it catches: Double-posted invoices, re-imported bank transactions, duplicate manual journals.

Detective controls (find what got through)

5. Intercompany balance matching

What it checks: Every intercompany receivable in Entity A has a matching payable in Entity B. Every intercompany sale matches an intercompany purchase. Balances net to zero across the group.

Why it matters: Intercompany mismatches are the number one consolidation pain point for multi-entity mid-market companies. One entity books the transaction this month, the other books it next month. Or one uses a different exchange rate. Or one records it as a loan, the other as a trade payable.

How to implement: Run a weekly matching report — not monthly. By the time you find mismatches at month-end, you’ve lost the context of what happened. Weekly catches timing differences while people still remember.

What it catches: Timing differences, FX mismatches, classification disagreements, missing entries, elimination errors in consolidation.

6. Trend break analysis

What it checks: Current period figures vs. prior period, same period last year, and budget. Any line item that deviates beyond a defined threshold gets flagged.

Why it matters: This is the most powerful detective control because it catches problems regardless of type. A revenue line that drops 40% month-on-month might be a posting error, a lost customer, or a classification change. The specific cause varies. The signal — something changed that needs explanation — is consistent.

How to implement: Automate a variance report for the top 20-30 P&L and balance sheet lines. Set thresholds: plus or minus 15% vs. prior month, plus or minus 25% vs. same month last year. Review the flags, not every line.

What it catches: Posting errors, classification changes, missing accruals, revenue recognition timing issues, cost overruns, anything that moves the number significantly.

7. Balance sheet substantiation

What it checks: Every material balance sheet account is supported by a detailed schedule that ties to the GL balance. Receivables schedule = receivables balance. Fixed asset register = fixed asset balance. Provisions list = provisions balance.

Why it matters: P&L errors eventually self-correct (this month’s missed accrual becomes next month’s catch-up). Balance sheet errors compound. An unreconciled receivable today is an unexplained write-off in 18 months.

How to implement: Define materiality thresholds for your business — which accounts need monthly substantiation vs. quarterly. Assign owners. The schedule must tie to the penny. If it doesn’t, the difference is the problem to investigate.

What it catches: Stale receivables, unrecorded liabilities, asset register discrepancies, accumulated rounding differences, reconciliation items that nobody ever resolved.

8. Cross-system reconciliation

What it checks: The same data point — revenue, cash, headcount, inventory — matches across all systems that record it. ERP revenue = CRM revenue = billing system revenue. Bank balance = GL cash balance = treasury system balance.

Why it matters: Mid-market companies running 2-4 systems will have different numbers for the same metric in each system. Not because any single system is wrong, but because definitions differ, timing differs, or integration was never designed to keep them aligned. APQC data shows multi-ERP organisations spend 2.3x more on the financial close than single-ERP companies. Most of that cost is here — reconciling across systems.

How to implement: Map every key metric to its source systems. Define which system is the “golden source” for each metric. Run automated matching at defined frequency. Investigate breaks above materiality threshold.

What it catches: Integration failures, definition inconsistencies, timing differences between systems, data that exists in one system but not another.

Corrective controls (fix and prevent recurrence)

9. Adjustment journal protocol

What it checks: Every manual journal entry follows a defined workflow — preparer, reviewer, approver — with documented rationale.

Why it matters: Manual journals are where data governance breaks down. A controller posts an adjustment to fix a reconciliation difference. The adjustment is correct this month. But it obscures the root cause, and next month the same difference appears. Manual journals should be the exception, not the process.

How to implement: Require a reason code for every manual journal (reclassification, accrual, error correction, intercompany). Require a second person to review journals above a threshold. Track the volume of manual journals per close — if it’s growing, your preventive controls are failing.

What it catches: Undocumented adjustments, recurring errors masked by recurring corrections, segregation of duties violations, the “I’ll fix it in the journal” culture.

10. Root cause tagging

What it checks: When a detective control finds a problem, the fix includes documenting why it happened — not just what was corrected.

Why it matters: Without root cause tagging, you fix the same problem every month. “Intercompany difference — adjusted EUR 15K.” Why? Was it a timing issue (post earlier), an FX issue (align rates), a process issue (one entity doesn’t record intercompany transactions promptly)? The fix determines the prevention.

How to implement: Add a root cause field to your reconciliation workpapers or journal entry form. Five categories is enough: timing, classification, system/integration, human error, process gap. Track frequency by category. If “timing” is 60% of your issues, you have a cut-off problem, not a data problem.

What it catches: Recurring errors, systemic process failures, integration gaps that generate the same exceptions every period.

11. Exception ageing

What it checks: How long reconciliation items and unresolved exceptions have been open.

Why it matters: Every finance team has a reconciliation spreadsheet with items that have been “pending investigation” for months. The older an exception gets, the harder it is to resolve — context is lost, people leave, the documentation trail goes cold.

How to implement: Age every open exception: 0-30 days, 30-60, 60-90, 90+. Escalate anything over 60 days. Anything over 90 days that can’t be resolved gets a decision: write it off, book a provision, or assign it to someone with authority to close it. Zero tolerance for items ageing beyond 90 days without a documented decision.

What it catches: Festering reconciliation items, unresolved intercompany differences, balance sheet items that accumulate over quarters and become material.

12. Close retrospective

What it checks: After each close cycle, the team reviews what went wrong, what took too long, and what should change.

Why it matters: This is the control that improves all other controls. Without it, you repeat the same close process indefinitely. With it, you identify which preventive controls to add, which detective thresholds to adjust, and which recurring corrections indicate a systemic issue.

How to implement: 30-minute meeting after each monthly close. Three questions: What took the most time? What error appeared that we should have caught earlier? What’s one thing we change for next month? Document the action. Follow up.

What it catches: Process decay, control gaps, opportunities to shift from corrective to preventive, team knowledge that hasn’t been formalised.

Where to start

You don’t implement all twelve at once.

Week 1-2: Turn on mandatory field enforcement (#2) and duplicate detection (#4) in your ERP. These are usually configuration settings that are already available but not activated.

Month 1: Add range checks (#3) for the top 10 transaction types by volume. Set the thresholds generously — you’re looking for outliers, not precision.

Month 2: Implement intercompany matching (#5) weekly and trend break analysis (#6) as part of the close.

Quarter 1: Build out balance sheet substantiation (#7), cross-system reconciliation (#8), and the adjustment journal protocol (#9).

Ongoing: Add root cause tagging (#10) and exception ageing (#11) to your existing reconciliation process. Start the close retrospective (#12) immediately — it costs nothing.

The goal isn’t perfection. It’s systematic. A finance team that runs even half of these controls consistently will spend less time on month-end, produce more reliable numbers, and be ready when the AI tools arrive — because AI on validated data works. AI on unvalidated data is expensive hallucination.