OTROTL network

The invoice control plane.

One place where every biller’s invoice lands, is read and understood, and can be tracked, searched, saved and shared.

INVOICES is a two-sided biller↔payer network. Billers onboard once and deliver invoices to every customer they have on the network. Payers get a single unified inbox across all of their billers — instead of a hundred vendor portals, inbox threads and PDF folders.

Uses your OTROTL single sign-on account.

Two sides, one record

Both sides work off the same canonical invoice — not a copy, a forward, or a re-keyed spreadsheet row.

For billers

Self-onboard into the biller directory, pass a tiered KYB verification, and deliver invoices straight into your customers’ inboxes over a single integration — API push, email, or file upload.

For payers

Every invoice from every linked biller in one inbox, extracted into structured fields, with aging views that show what is overdue and what falls due next.

What it does

Intake, extraction, directory, portal, approval.

Multi-channel intake

Invoices arrive however the biller sends them, and land as one canonical record.

API push, direct upload, and parsed .eml messages with attachments
Content-hash de-duplication, so the same invoice never lands twice
Untrusted payloads are quarantined before anything downstream reads them
Every state change is written to an append-only event log

Extraction pipeline

Wildly different vendor formats become the same set of structured fields.

Content scan → OCR → structured extraction of header and line items
A confidence gate routes low-confidence extractions to human review instead of trusting them
Semantic search over extracted content via vector embeddings
Document text is treated as data, never as instructions to the extractor

Biller directory & KYB

Payers can see who is actually behind an invoice before they act on it.

Biller self-onboarding behind a tiered KYB gate (unverified → tier 1 → tier 2)
A searchable directory of verified billers, with anti-enumeration controls
Collision detection on look-alike biller identities
Account linking is consent-gated — the payer confirms the link

Payer portal

The four verbs that actually matter once the invoices are in one place.

Track, search, save and share — on the shared fleet portal surface
Aging views: overdue, due in 0–7, 8–14, 15–30 days, later, and no due date
Saved views and faceted filters across the whole invoice history
Row-level isolation: a tenant sees only its own invoices

Approval workflow

An explicit, audited lifecycle on the invoice record — no invoice advances by accident.

A strict state machine: only declared transitions are legal
Dual-control approval, so one account cannot both raise and approve
Dispute and reject are first-class outcomes, not dead ends
Who approved what, and when, is recorded per transition

Built on the fleet

INVOICES composes existing OTROTL services rather than reinventing them.

OTROTL single sign-on for every account — no separate password
The shared portal for track / search / save / share
Shared vendored assets and the fleet health and observability contract
Deliberately small: it owns the invoice model, intake, extraction, and the orchestration between them

Invoice lifecycle

Every invoice moves through declared states, and every move is recorded.

RECEIVED
SCANNED
EXTRACTED
NEEDS_REVIEW
READY
APPROVED

Anything that fails a scan or a trust check is diverted to QUARANTINED rather than continuing. From READY, an invoice can also be DISPUTED and returned for correction; from NEEDS_REVIEW it can be REJECTED outright.

Why it is built this way

Invoices are money, and they arrive from parties you only partly trust.

Business email compromise. A biller identity has to be verified through KYB before it is presented to payers as legitimate.
Duplicate and inflated billing. De-duplication runs on ingest, and extracted totals are reconciled against the line items.
Malicious file payloads. Attachments are scanned and quarantined before any parser or model is pointed at them.
Prompt injection. Text inside an invoice is never allowed to act as an instruction to the model that reads it.
Tenant leakage. Isolation is enforced in the database with row-level security, not only in application code.
Silent failure. Trust checks are fail-closed: when a control cannot be evaluated, the invoice stops rather than passing.