synthetic cfo Back to synthetic cfo
Synthetic Oracle data

Synthetic Oracle ERP data with a ground-truth answer key

Oracle Cloud worlds are generated on Fusion-shaped tables, not generic schemas: Payables in AP_INVOICES, AP_PAYMENTS and AP_HOLDS, Receivables in AR_INVOICES and AR_RECEIPTS, General Ledger journals in GL_JE_HEADERS and GL_JE_LINES, fixed assets in FA_ADDITIONS and FA_BOOKS, cash management in CE statement and reconciliation tables.

The full cycle, closed

All seven modules run on Oracle exactly as they do on SAP. Invoice holds are real event rows - placed, reviewed, released before payment, with a population honestly still on hold at the period cutoff. Every payment's bank statement line carries its bank reference, and the per-bank reconciliation is proven to the cent, with outstanding items and deposits in transit on a per-item schedule.

The two-ERP group

The intercompany group pairs an Oracle subsidiary with a SAP subsidiary under one holding company: an intercompany register, a line-by-line elimination schedule with matched, unmatched and innocent in-transit states, and the one fraud pattern that only exists across two systems at once - seller revenue with no matching buyer payable. It runs as a multi-year arc, and a prior year's in-transit items resolve in the next January's register while a fraud orphan never does.

Labelled, scored, reproducible

Every planted scheme is recorded in the answer key at plant time with innocent look-alikes beside it, packages regenerate byte for byte from a seed, and the published scoring of real detectors against this data - including how often they are wrong - is public on the proof page.

The generator built into the database

The database itself can now fill an empty schema with rows a language model writes from the table definitions and a prompt, with the declared foreign keys kept. For populating a clone or a demo it is the right tool, and it is free. It is not a ledger. The rows fit the tables, but no debit has to equal a credit, no invoice has to clear to a payment, nothing is labelled, and a language model call does not promise the same rows twice; its own documentation says the model can hallucinate. A synthetic cfo world is built the other way round: the accounting comes first and the tables are filled from it, so the books balance to the cent, every fraud is recorded at plant time with an innocent look-alike beside it, and the same seed regenerates the package byte for byte with a certificate. The source layer ships as workbooks and CSV per table with the real column names, so it loads wherever a CSV loads, and the four tests on the forensic-grade page settle which is which in ten minutes.

Keep reading