Not every discrepancy in a financial ledger is a red flag. Some are noise — rounding, accrual timing, accounting policy differences that get normalized in the QoE. The discrepancies that matter are the ones that are systematic, that cluster around specific time periods or transaction types, or that cannot be explained by the documents in the data room.
Experienced analysts develop a sense for which discrepancies warrant escalation and which are administrative. This guide captures that pattern recognition in explicit form — because the ability to distinguish signal from noise in a ledger is one of the most valuable skills in buy-side diligence.
Red flag #1: Round-number clustering
Real business transactions rarely fall on round numbers. A vendor invoice for $50,000.00 is less plausible than one for $47,832.14. When a ledger has an unusual concentration of entries with round amounts — $10,000, $25,000, $100,000 — that's worth investigating. Round numbers can indicate estimated accruals that were never reversed, intercompany transfers that aren't arm's-length, or, in fraud cases, constructed entries designed to fill a target.
Benford's Law analysis on large ledgers can surface distribution anomalies automatically: the leading digits of naturally occurring financial data follow a predictable distribution. Deviations from that distribution don't prove fraud, but they do identify transaction populations worth reviewing more carefully.
Red flag #2: Year-end concentration
A disproportionate volume of transactions in the last two weeks of a fiscal year is one of the most consistent indicators of revenue management. Sellers accelerate revenue recognition, defer expense recognition, and reverse accruals before year-end to hit EBITDA targets. The pattern shows up clearly in a month-by-month transaction distribution.
The tell is not just volume — it's reversal. If December shows a spike in revenue transactions that partially reverse in January, that's a cash vs. accrual discrepancy worth understanding. If it happens in multiple years, it's a systematic pattern that should be reflected in the normalized EBITDA.
Red flag #3: Vendor concentration with thin documentation
High spend with a small number of vendors is common in many industries. High spend with a small number of vendors who have minimal documentation in the data room is different. If 30% of the company's COGS flows through two vendors and there's one contract and three invoices supporting that spend, you have a documentation gap that should trigger follow-up.
The specific risk varies by context. In some cases, it's simply poor document management by the seller. In others, it's a related-party relationship that wasn't disclosed, or a vendor whose terms aren't actually contractually fixed. Both are material to valuation.
Red flag #4: Reference number discontinuities
Sequential reference numbers in a ledger or invoice sequence tell a story about transaction volume over time. Discontinuities — jumps in sequence, reused numbers, numbers that appear in the wrong chronological order — can indicate deleted transactions, backdated entries, or a migration between accounting systems that was handled inconsistently.
- —A gap from INV-2024-00412 to INV-2024-00631 suggests approximately 218 invoices are either missing from the data room or were deleted from the ledger
- —A reference number appearing in January that precedes a number that appears in the prior November suggests backdating
- —Duplicate reference numbers on different transaction dates suggest either a numbering error or a duplicate entry
Red flag #5: Counterparty name changes mid-period
A vendor that appears under one name for three years and a different name in the final year may have rebranded, been acquired, or changed its entity structure — all benign. Or the name change may reflect an undisclosed related-party transaction, a shell company substitution, or an attempt to obscure a payment pattern. The question worth asking: did the underlying contract change, and is there a new contract in the data room?
Red flag #6: Document dates that don't match transaction dates
An invoice dated three months after the transaction it supposedly supports is a documentation red flag. It could be a legitimate after-the-fact invoice from a vendor who bills on delayed schedules. It could also be a reconstructed document created to support a transaction that was entered without proper documentation at the time.
The distinguishing factor is whether the pattern appears once or repeatedly. A single late invoice in a 10,000-row ledger is noise. Twenty late invoices clustered around the same vendor or the same time period is a pattern.
How systematic reconciliation surfaces these patterns
All six of these red flags require the same underlying capability: the ability to cross-reference every ledger entry against its supporting documentation at scale. Manual reconciliation catches individual instances but misses population-level patterns. Automated reconciliation runs the full ledger in one pass, which means statistical patterns become visible that would never surface from sampling.
The round-number clustering and year-end concentration patterns are invisible if you're reviewing 500 out of 10,000 transactions. They're obvious when you have a structured output of all 10,000 matches and mismatches. That's the difference between finding a discrepancy and understanding a pattern.