Accounts Payable

Architecture

Key specifications

What it does for you

Three payables failures recur across the industry and all three are invisible to the people running the cycle. A posting run aborts on batch contention and is filed as though it succeeded -- the report still balances, because nothing moved. A payment is released through an open compliance gate: no taxpayer certificate on a first payment, waivers missing from a subcontractor's lower tiers, insurance expired before the payment date. And a routing matrix drifts until a job maps to no workflow, or one person holds both data entry and final review. Each is deterministic to detect from artifacts that already exist, and none of them needs a model's judgment.

The seeded demo runs every control over every document set⁷. The CLI generates thirty-one fictional document sets -- one clean baseline plus one planted defect per control -- and runs all thirty controls over each. The clean set reports PASS with every control held; each defective set reports the exact control it was built to trip. The run exits 2 because the corpus deliberately contains failures.

Absent evidence must not read as a passing control⁸. One fixture removes an entire artifact type from its document set. Every control that reads that artifact returns nothing, which without a structural precondition would render as a clean result. The set_complete control is registered first and fails the set, so the report opens with proof that the controls below it had something to read.

Every control must prove both of its sides⁹. Each of the thirty controls is exercised against its own planted defect, which it must catch, and against the clean baseline, where it must stay silent. A coverage test asserts the planted-defect set and the registry are the same set, so a control cannot be added without a fixture that exercises it, and an implementation that always passes or always fails cannot satisfy the suite.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Money is integer cents everywhere and is compared with exact equality; there is no tolerance band anywhere in this engine, and a non-integer amount is rejected rather than coerced.
• The engine is read-only: source artifacts are hashed before and after a run and asserted byte-identical, so it is structurally incapable of introducing the defects it looks for.
• One planted defect exists per registered control, and a coverage test asserts the two sets are identical, so a control cannot be added without a fixture that exercises it.
• The structural precondition control runs first, so a document set missing an artifact type cannot report as clean simply because the controls that read it never ran.
• The package declares no runtime dependencies; the optional workbook rendering is behind a guarded import and never byte-compared.

Operating limits

• The engine never posts, releases a payment, drafts a journal entry, creates an import payload, or mutates a source system. It has no connection to a ledger, payment provider or approval system.¹⁴
• A PASS verdict means the implemented mechanical controls found nothing; it is not sign-off, audit assurance, or authorization to pay.¹⁵
• The engine reads structured document sets, not scanned images. There is no optical character recognition, and an artifact with no machine-readable content is reported as unclassifiable rather than guessed at.¹⁶
• There is no remediation loop. Resyncing to authority and booking adjustments is a mutation, which a read-only control engine must not perform; this engine is a sensor other loops consume.¹⁷
• All shipped data is fictional and seeded. The engine names no commercial software product and carries no real vendor, entity, person, or document identifier.¹⁸

See it run

Integration

Distribution: public repository, MIT license.