Financial audit

Test transaction-level assertions, investigate control exceptions and retain the supporting evidence behind an accounts-payable review.

For finance operations, internal audit and external auditors.

Where it fits in your workflow

Use this when a supplier invoice is ready for payment, a payment release needs an independent check, vendor bank details change, or an audit team reviews a transaction population. Supply the invoice and the records that establish its amount, counterparty, applicable controls and comparison history.

1. Define the assertion and control. Choose the transaction or decision to test. An invoice review can check arithmetic, duplicate criteria, supplied vendor status and whether a purchase-order reference is present. An invoice-approval decision separately checks authority, independence and whether the invoice supports approval; it does not check approval timing.
2. Assemble supporting evidence. Include invoice lines, vendor master data, relevant comparison invoices and the period under review. For substantive testing, retain the original invoice and any purchase order, receipt or delivery evidence in your audit workpapers; the API checks the structured inputs you supply.
3. Assess materiality and follow up. The reviewer sets materiality and the nature of follow-up in the engagement. An amount, repeated exception or control deficiency can inform that judgment. Materiality is not an automatic engine setting that suppresses a failed assertion or changes a false verdict.
4. Keep a traceable audit trail. Route the exception to its control owner, record the supporting evidence and resolution, and keep the returned assertions, input hash and configuration with the review. Approval and payment actions remain in the finance system.

What to send

• Supplier invoice. Stable item ID, vendor_id, invoice_number, invoice_date, amount as a decimal string and currency. Supply line_items with quantity and unit_price for the arithmetic check, and a po_number when the invoice has a purchase-order reference.
• Counterparty and people. Vendor status and master data, plus the people who entered, approved or released a transaction where those checks apply. Employee records support the expense and independence checks for the relevant item types.
• Rules and authority. Use the pack's po_thresholds parameter, one amount per currency, for the purchase-order requirement; an invoice in a currency it does not list holds only with a PO reference. invoice_round_units and invoice_round_minimums set the round-amount indicator per currency. Approval limits, approval authority, role assignments and bank-change records belong in context.references for the checks that use them.
• Comparison population and period. Related invoices, payments or approvals in context.records, plus the engagement period. An empty list states there are no comparison records in the supplied scope; it does not prove that no other records exist in the business.

Use POST /api/v1/verify for one item or POST /api/v1/audits for a population with shared context. See the request structure.

A $24,800 supplier invoice without a purchase-order reference

The synthetic Northstar IT Supply invoice INV-2026-0841 lists 20 laptops at $1,240.00 each. Its $24,800.00 total reconciles, the supplied vendor is active, and the request provides an empty comparison-invoice population. No purchase-order reference is supplied, although the applicable PO threshold is $1,000.00.

The po_present assertion fails and the overall verdict is false: the invoice is above the PO threshold without the required reference. That is a specific accounts-payable control exception, not a conclusion that the goods are fictitious or the total is misstated. The reviewer obtains the purchase order or documents the exception with the control owner, then assesses its significance and any further substantive testing.

Recorded verdict: false. The table below comes from the saved response.

Synthetic example. Response computed by the local engine in the production configuration. This page displays a saved example, not a new verification request. Sensitive identifiers are masked in public examples.

{
  "use_case": "financial-audit",
  "item": {
    "type": "invoice",
    "id": "INV-2026-0841",
    "data": {
      "vendor_id": "V-1042",
      "invoice_number": "INV-2026-0841",
      "invoice_date": "2026-09-18",
      "amount": "24800.00",
      "currency": "USD",
      "description": "20 business laptops for the finance team equipment refresh.",
      "line_items": [
        {
          "quantity": "20",
          "unit_price": "1240.00",
          "description": "Business laptop, 16 GB RAM, 512 GB SSD"
        }
      ],
      "tax_amount": "0.00",
      "discount_amount": "0.00"
    }
  },
  "context": {
    "records": {
      "vendor": [
        {
          "id": "V-1042",
          "name": "Northstar IT Supply",
          "created_on": "2024-02-12",
          "status": "active"
        }
      ],
      "invoice": []
    },
    "engagement": {
      "entity": "Illustrative procurement audit",
      "period": {"start": "2026-07-01", "end": "2026-09-30"}
    }
  }
}

{
  "id": "ver_e8d57ccdc33a72cc",
  "object": "verification",
  "created_at": "2026-10-07T06:12:32Z",
  "use_case": "financial-audit@4",
  "item": {"type": "invoice", "id": "INV-2026-0841"},
  "verdict": "false",
  "probability_true": "0",
  "probability_basis": "deterministic",
  "certainty": {
    "value": "0.9987",
    "basis": "holdout",
    "stratum": "false_deterministic",
    "bound": "0.00133",
    "measured_on": 2253,
    "errors": 0
  },
  "undecided": [],
  "assertions": [
    {
      "id": "not_duplicate",
      "test": "procedure:not_duplicate@4",
      "outcome": "holds",
      "error_bound": "0",
      "evidence": ["/item/data/invoice_number", "/item/data/amount"]
    },
    {
      "id": "arithmetic",
      "test": "procedure:arithmetic@4",
      "outcome": "holds",
      "error_bound": "0",
      "facts": {"computed": "24800.00", "stated": "24800.00"},
      "evidence": ["/item/data/line_items", "/item/data/amount"]
    },
    {
      "id": "vendor_active",
      "test": "procedure:vendor_active@4",
      "outcome": "holds",
      "error_bound": "0",
      "evidence": ["/context/records/vendor/0/status", "/item/data/invoice_date"]
    },
    {
      "id": "po_present",
      "test": "procedure:po_present@4",
      "outcome": "fails",
      "error_bound": "0",
      "message": "No PO for an invoice of 24800.00, above the threshold of 1000.00.",
      "facts": {"required": true},
      "evidence": ["/item/data/amount", "/item/data/po_number"]
    },
    {
      "id": "goods_specific",
      "test": "question:invoice_specific@1",
      "outcome": "not_asked",
      "message": "Not asked: a deterministic test already fails this item, so the model cannot change its verdict.",
      "facts_given": {"line_count": 1, "po_present": false},
      "evidence": ["/item/data/description", "/item/data/line_items"]
    }
  ],
  "indicators": [
    {
      "id": "round_amount@2",
      "family": "amount_shape",
      "points": "0.5",
      "facts": {"amount": "24800.00"},
      "evidence": ["/item/data/amount"]
    }
  ],
  "risk": {
    "points": "1.10",
    "probability": "0.0060",
    "basis": "prior",
    "base_rate": "0.002",
    "reasons": [
      {"source": "assertion:po_present", "points": "0.60"},
      {"source": "indicator:round_amount@2", "points": "0.50"}
    ]
  },
  "scope": {
    "stratum": "false_deterministic",
    "evidence": "supplied",
    "skipped": [],
    "certainty_target": "0.995",
    "deterministic_only_verdict": "false"
  },
  "configuration": "cfg_c924a60e74c0",
  "input_sha256": "e029d0fb9aaca2da01aadba1467472ac90c6f3c293c2df0c72ce273ff2fc0019",
  "usage": {"questions_asked": 0, "questions_cached": 0, "model_ms": 0}
}

Supported records and checks

These definitions are generated from the registered use-case pack. A procedure computes a result from the supplied data; a question can decide a check only when it is qualified for the model and meets its thresholds. The descriptions name the checks; they do not authenticate the underlying business events. Supplied fields, defaults and comparison populations determine what each procedure can establish. Risk weights help prioritize review and are not probabilities.

• expense: An employee expense claim.
• approve_expense: Approval of an expense claim.
• vendor: A vendor master record.
• create_vendor: Creation of a vendor record.
• change_vendor_bank: A change to a vendor's bank account.
• invoice: A vendor invoice.
• approve_invoice: Approval of an invoice.
• payment: A payment to a vendor.
• release_payment: Release of a payment.

expense

An employee expense claim. Required data fields: employee_id, date, amount, currency, category.

approve_expense

Approval of an expense claim. Required data fields: actor, at, on, outcome.

vendor

A vendor master record. Required data fields: name.

create_vendor

Creation of a vendor record. Required data fields: actor, at, on, outcome.

change_vendor_bank

A change to a vendor's bank account. Required data fields: actor, at, on, outcome.

invoice

A vendor invoice. Required data fields: vendor_id, invoice_number, invoice_date, amount, currency.

approve_invoice

Approval of an invoice. Required data fields: actor, at, on, outcome.

payment

A payment to a vendor. Required data fields: vendor_id, payment_date, amount, currency.

release_payment

Release of a payment. Required data fields: actor, at, on, outcome.

Judgment questions and qualification

The table describes published evaluation evidence. For the qualification attached to the running service, inspect this use case’s live definition. A model answer can be recorded without deciding a check. How qualification works.

Scope and limits

• The purchase-order check tests whether a reference is present above the configured threshold. It does not authenticate a purchase order, match its lines to the invoice or verify receipt of the goods.
• Correct invoice arithmetic establishes that the submitted lines, tax and discount reconcile. It does not independently establish occurrence, completeness or the authenticity of supporting documents.
• Receipt status, vendor status and bank-change verification are supplied fields. An account match or a recorded callback does not authenticate the supplier's payment instruction or establish the independent origin of the contact used to verify it.
• The vendor-status check uses the supplied master status, defaulting to active if omitted, and compares a creation date when present. It does not reconstruct historical status changes.
• Materiality remains the reviewer's planning and evaluation judgment. The current API does not accept materiality as an engagement field, and a small amount does not automatically waive an assertion.
• The checks cover the registered transaction and decision types below. They do not produce a financial-statement opinion, tax conclusion or a complete assessment of internal control.

A true verdict means all applicable, unskipped checks hold within the decision gates; false means at least one qualifying failure decided the item. Other assertions can remain unresolved even with a false verdict. An uncertain verdict means the evidence and decision gates do not support a decided result. Review the assertion outcomes and evidence before taking a business action. Read the decision method.

Published evaluation results

These measurements use synthetic populations with generator-stated truth. Coverage is the share receiving true or false verdicts, not measured accuracy on your records. Read the metrics and their limits.

Results for financial-audit@4.

financial-audit@4 is measured on its own holdout dataset (0043b0a536a0bc1c…), not the one financial-audit@1, financial-audit@2 and financial-audit@3 were measured on, so its numbers are not directly comparable with theirs.

Faults

Look-alikes

Holdout seeds 101, 102, 103, 104, 105, 106, 107, 108, 109, 110; dataset SHA-256 0043b0a536a0bc1c….

Versions

A request naming financial-audit runs the current version. Name a version, such as financial-audit@1, to keep the checks you integrated against; a superseded version stays served unchanged. Test labels in a response carry the version that ran them.

Schemas and integration

Every item, record and reference schema is at GET /api/v1/use-cases/financial-audit.

Supported context record types: employee, expense, approve_expense, vendor, create_vendor, change_vendor_bank, invoice, approve_invoice, payment, release_payment.

Supported reference sets: approval_limit, approval_authority, user_role, vendor_bank_change, calendar, personal_terms.

Start with a reviewable sample

Begin with a defined transaction population and control objective. Include known exceptions, complete records and cases with missing evidence; compare the findings with your audit workpapers before expanding the workflow.

Try the console · API quickstart · Full API reference

From the blog

• The batch boundary changed the audit verdict
• The bank account matched. It still wasn't the supplier's.