Benford's law in generated ledgers, and what it proves
Benford's law says the leading digit of naturally occurring financial figures is a one about thirty percent of the time, falling away to under five percent for a nine. It is the first test people run on synthetic data, and the wrong test to decide anything on. Both halves of that sentence matter.
Amounts here are not drawn from a flat range. They come from quantity times price across a catalogue, with seasonality, industry mix and a calibration that keeps purchases, inventory and capital spend in a sane relationship to revenue. Multiplicative processes of that kind produce a Benford-shaped distribution on their own, which is why every package ships a statistical realism report containing the digit analysis rather than a promise about it.
A digit distribution is a property of a column. It says nothing about whether a purchase order has a goods receipt, whether a vendor's bank account also belongs to an employee, whether a release was recorded after the payment, or whether a transfer credit has a counter-entry anywhere. Passing Benford is a floor, not a finding.
The published proof runs three detectors of deliberately different skill against a copy of the data with the answer key physically absent. The generic statistical tier, which is outlier and digit analysis, scores an F: on the SAP world it reaches an F1 of 0.11, and it flags 575 records in a fraud-free twin of the same company, where the right answer is zero. That failure is the most useful number the project publishes, because it says what kind of fraud this is: not large, not oddly rounded, but behavioural. It hides in event order and in relationships between documents, where a digit test cannot see.
The tests that work are relational and temporal. Compare a supplier bank account against the payroll file. Look for a release event dated after the payment run. Look for a transfer credit with no matching debit anywhere in the bank world. Group orders by supplier and day and see which cluster under an approval threshold. On the published run, targeted forensic rules of that shape reach recall of 0.99 on SAP and 0.99 on Oracle, and their precision is still well under half, because the innocent look-alikes are there to be tripped over.
Run it as a smoke test on any vendor's synthetic data, ours included. If the digits are wrong, the amounts were drawn from a distribution rather than built by an accounting process, and nothing downstream is worth measuring. If the digits are right, you have learned that one thing and should move on to the relational tests immediately.