Autonomous resolution rate (last run)
-
OPERATE — 01 / DASHBOARD
Dashboard
Executive KPIs, the value summary, and run history: the headline numbers of the active case, computed live from its latest run. Loading a case stages it - invoices and wires land in the workspace untouched - and one explicit run executes the pipeline - five agents in sequence, with the Briefing agent composing on demand - so you always see the before and the after.
One workspace, one case: the case bar above is the single source of truth. Load a case (demo, a use-case pack, the builder, or your own uploaded files) and the Dashboard, Ledger, Run, Approvals, Forecast and the assistant (bottom right) all work on exactly that data. How a payment flows: the engine compares each staged payment with the case's unpaid invoices. If it finds an exact match (nothing left unexplained) and its confidence passes the policy threshold, it auto-posts it - unless the amount crosses the maker-checker threshold, which holds even an exact match for a second approver. Anything less becomes a proposed match for a person to approve, or an exception with a suggested next step. On a first visit the demo case loads in its staged state: the readiness panel shows the real portfolio waiting, and one click on Execute runs the solver in front of you - every number after that is counted from that run's stored records. Reset to empty in the case bar clears the workspace whenever you want to start clean.
What SlateMatch has done for you
Run a case and this panel counts the money the agent posted, the analyst hours it returned and the deduction recovery it set in motion.
Save & retrieve this session
Save the workspace exactly as it stands - the case, its runs, every decision, approval and draft - and get a session ID. Enter that ID here on any later visit and the workspace comes back in the exact saved state. Saves live on this server for the life of the deployment; a redeploy clears them.
Unapplied cash in suspense
-
Avg solver latency
-
Invoices settled (last run)
-
Open exceptions (last run)
-
Touchless rate (last run)
-
Payments posted with no human touch, out of all payments in the run
SAP S/4HANA BAPI & EBRR
DZ clearing
Balanced DZ clearing + ASC 606 dispute reserve ready - click to open the SAP payload
Solver Engine
HiGHS MILP + Rust
HiGHS MILP + Rust subset-sum kernel (0¢ residual rule) - click for kernel health
Agent mode
-
AI suggests; fixed rules decide. Tenant API keys are hashed on the server and never shown again.
01Component Guide - DashboardExpand guide
What it is
The home screen: the headline results, a summary strip (the ribbon) worked out from the latest run, and the history of every run.
How it is calculated
Touchless rate = payments posted on their own, divided by all payments in the run (hard payments are counted, not hidden). Unapplied cash = the total of leftover amounts across the run's matches. Latency = the average solver time stored on each match.
What it means
If the unapplied-cash figure grows from run to run, money is arriving faster than the agent can explain it. That points to poor remittance data, not a weak solver.
What you can do
Run the demo, upload your own files in the Upload Center, or open any past run in the table to see its evidence.
Run history
Every batch the agent has executed in this workspace. Select a run to inspect its matches and exceptions.
No runs yet. Load a case or upload payments to create the first run.
OPERATE — 02 / USE CASES
Use Cases
10 synthetic scenario packs and the Custom Case Builder. Stage a pack to inspect it first, or stage and run it in one click; the builder lets a reviewer assemble a case of their own and watch the agent work on it.
Use case packs & the custom case builder
Custom Case Builder
Build your own test: enter invoices and one payment, and they load into the shared workspace as a case like any other - the builder's run button loads and runs it, then opens Run Reconciliation with the full derivation on the match. Bring the case you think breaks it.
Sums the ticked invoice rows, subtracts the claimed deduction, and fills the payment amount and references - so the case you build is one the solver can actually solve.
OPERATE — 03 / UPLOAD CENTER
Upload Center
Invoices CSV, Payments CSV, and the Capture Agent remittance parser - three doors into the same workspace. The invoices file defines the ledger itself; the payments file stages wires and reconciles them in one call; only the remittance parser verifies its references against the open ledger before anything is staged.
Upload & capture - files, CSV and pasted remittance
UPLComponent Guide - Upload CenterExpand guide
What it is
Where real work enters: your invoice list and your bank payments, as CSV files, with automatic column matching and a list of any rows that failed.
How it is calculated
Column names are matched to our fields using a synonym list; the mapping used is shown to you. The file is fingerprinted (a hash of its column names) so the same layout is recognised next time. Payments are matched as soon as they are imported, using the current policy.
What it means
An import with no failed rows means your bank and ERP files already line up with our fields. Most first files do not - the quarantine list is exactly the list of what to fix.
What you can do
Drop a file, paste the CSV text, or start from the samples and templates. Fix failed rows in your source file and import again.
1. Open invoices (AR ledger)
One row per open invoice, amounts in major units (e.g. 1250.00). Importing replaces the workspace by default - an invoices file is a whole ledger, not an addition. Use "Add to current ledger" only when the file is a second part of the same book (a subsidiary, a later extract).
Drop an invoices file here, or click to choose
CSV or text: invoice id, customer, amount, PO number, discount %, age, days to due. A dropped file imports as a new workspace.
2. Payments (bank / lockbox)
One row per received payment in a CSV; a single remittance advice in any other file. On CSV import, the workspace's whole staged set is reconciled - new wires join the active run, they never replace it.
Drop a payments file here, or click to choose
A payments CSV, a remittance email (.txt / .eml), a PDF payment advice, or a screenshot (PNG / JPG) - the Capture Agent reads them all, and every reference is checked against the open ledger
Remittance and wire input - the Capture Agent
Step 01 of the agent. Paste any remittance email or wire advice - the moment text lands in the box, the parser reads it automatically and fills the wire card below. The verifier checks every reference against the open ledger, and the verified wire can be staged into this workspace, ready to reconcile in Run. Nothing is trusted on the AI's word alone.
INBOUND WIRE AMOUNT
not parsed yet
Tip: this sample references INV-1001 and INV-1002 from the demo case - load the demo case first, or paste your own buyer's email.
AI extraction layer
Checking which extraction engine is active...
Staged in this workspace
Payments currently staged in the active case, waiting to run or already settled. Imports land here first - nothing stays stranded on this page.
OPERATE — 04 / RUN RECONCILIATION
Run Reconciliation
Five agents execute in sequence on the active case; the sixth, Briefing, composes its summary on demand. The flagship match is already open below - its cash conservation derivation and the why-not counterfactual proof on screen, nothing buried behind a click.
JD LINKThe role asks for custom algorithms for matching and reconciliation. This page is that engine, running live on the active case.
Step 1 - narrow the list: for each payment, the engine first narrows the unpaid invoices using the evidence it has, in this order: invoice references in the remittance, then the purchase order, then OCR-repaired references, then an exact amount on the payer's own ledger, then a fuzzy payer-name match, and only then that customer's whole open ledger. The solver never searches beyond the paying customer's ledger. Step 2 - solve: the MILP solver picks the set of invoices whose total, after discounts and any accepted deduction, equals the payment exactly (the cash conservation equation). Among exact sets it prefers older invoices, and it treats any unexplained leftover (residual) as very costly - a penalty of 1,000,000 - so it would rather propose nothing than hide a difference. Open any match to see its invoices and a why-not check for an invoice it did not pick. An invoice used by one payment cannot be used again in the same batch, and sending the same batch twice replays the first result instead of posting twice.
The agent team on this run
Run a batch and the five pipeline agents appear here with their measured timings; the Briefing agent composes on demand. Click any agent to inspect the payload it handed to the next.
ⓘ︎ View 6-Agent Algorithms & KPI Definitions ▾
Six named agents, each with its algorithm and the KPI it is judged on, printed in the open. Watch them work in the live lanes below.
| Agent | Algorithm | Judged on |
|---|---|---|
| Capture Agent | LLM extraction (Gemini when keyed) + deterministic fallback, then a ledger verifier | References verified, zero invented |
| Linking Agent | Exact references, PO match, OCR repair, amount-plus-payer, Jaro-Winkler fuzzy (0.88), whole-ledger fallback | Payments linked to the right customer |
| Matching Agent | MILP under a cash conservation equation (HiGHS), Rust subset-sum kernel | Exact-match rate, residual zero |
| Deduction Agent | Reason-code classification + z-score anomaly detection | Spikes caught, codes assigned |
| Policy Agent | Expected-value dispute rule, maker-checker thresholds, tolerance write-off | Nothing posts past policy |
| Briefing Agent | Grounded generation over run records (Gemini when keyed) | Every run ends with a brief and next actions |
Staged payments - the active case
These are the payments of the case in the bar above, staged in the one shared workspace. Running settles them against the case's open ledger - and the Dashboard, Ledger, Approvals and Forecast all update from the same run.
Matches
Nothing run yet in this view.
Exceptions
Exceptions from the run appear here, each with a recommended action.
RUNComponent Guide - Batch reconciliationExpand guide
What it is
One full pass of the real engine over a set of payments: narrow the candidates, solve the matches, judge deductions, and raise exceptions for the rest.
How it is calculated
For each payment: the candidate list narrows by reference, then PO, then OCR repair, then amount-plus-payer, then fuzzy payer name, then the customer's whole ledger. The solver then finds the invoice set that equals the payment exactly, preferring older invoices. The confidence rule and the auto-post rule are on the Methodology page, and every match shows its own worked calculation (its derivation).
What it means
AUTO_POSTED rows are finished work. PROPOSED rows are the agent asking a person to approve. Exceptions are the agent refusing to guess - each one says what to do next.
What you can do
Open any match to read its worked calculation and to test why another invoice was not picked. To change behaviour, edit the rules in Policy Studio and run again.
Held for sign-off - the maker-checker queue
Maker-checker sign-off queue
Full width, on the page - approve individually, or post every solved held match in one action (an unmatched wire in the queue is decided on its own).
Matches the agent solved but would not post alone - because policy held them (for example the maker-checker threshold) or a person must sign - plus any wire the agent could not match at all, held here so a person decides its fate. Approving a match posts it; approving an unmatched wire parks it in suspense and issues no document. Rejecting records the decision and takes the item out of the queue. Every decision is written to the audit trail.
OPERATE — 05 / SAP BAPI & EBRR
SAP BAPI & EBRR
Where cash application stops being a demo: the solver's own numbers, in the ERP's document shape. One balanced DZ clearing document per cleared payment, generated live by erp_sap.py, plus the ASC 606 / IFRS 15 dispute reserve for the run's claims.
Every document here is built from a stored match - its derivation equation supplies the cash, discount and deduction amounts, so debits equal credits to the cent by construction, and the balanced flag is asserted on every document. No ERP is connected; the payload is the exact BAPI_ACC_DOCUMENT_POST structure an S/4HANA system would receive.
Documents generated
-
One DZ clearing document per cleared payment in the latest run
Balanced journal total
-
Total debits = total credits across the run's documents
Document type
DZ - customer payment
BAPI_ACC_DOCUMENT_POST, SAP S/4HANA shape
ASC 606 dispute reserve
-
Claims reclassified to disputed receivables (GL 121500), revenue untouched
Debit vs credit - the GL posting table
Pick a cleared payment; its journal is grouped by GL account below, and its full payload is open underneath.
Run a case and its documents appear here.
BAPI_ACC_DOCUMENT_POST payload
The exact JSON the ERP would receive for the selected payment.
No document selected yet.
ASC 606 / IFRS 15 EBRR - dispute reserve journal
No dispute claims in the latest run.
INSIGHT & GOVERNANCE — 08 / OUTBOUND MAIL HUB
Outbound Mail Hub
Every outcome of the agent, turned into the business document it should become: a recovery claim for a short-pay, an inquiry for an unidentified wire, a settlement confirmation for cleared cash, and dunning for what is still open. Drafts are composed from the run's own records - nothing here is a static sample.
JD LINKThe role asks for agents that finish the work, not just the match. This hub is the finishing: each of the four mail categories is wired to a live data stream - the Deduction Agent, the exception queue, the settlement ledger, and the forecast's residual book.
Four streams, one hub. Category 1 comes from the Deduction Agent's decisions in the latest run. Category 2 comes from that run's exceptions. Category 3 is generated by the run itself and by every maker-checker approval - a draft lands in the Outbox the moment cash clears, citing the SAP clearing document. Category 4 is the post-run residual ledger, segmented into dunning tones. Honesty rule: a draft is a draft. A mail is only marked sent when a configured mailbox's server accepts it; until then sends are recorded in the Outbox as recorded_not_sent, with the reason shown.
Pick a stream above - the first dispute claim opens itself.
Outbox - generated, recorded and sent
Every draft the agents generate and every mail sent from this product, newest first, with its true status.
INSIGHT & GOVERNANCE — 06 / LEDGER
Ledger
The financial book: every open AR invoice and every staged payment, with inline cell editing. An edit never rewrites a stored match - it flags the case for a re-run, and the re-run is what changes the numbers.
The two sides of the equation - open AR ledger & staged wires
Open invoices
-
Across all customers
Open value
-
Gross receivables awaiting cash
Overdue value
-
Due date already passed
Staged payments - wires waiting to run
The payments staged in the active case, which the next run reconciles against the ledger above. Once they have run, their matches and exceptions are on the Run page.
INSIGHT & GOVERNANCE — 07 / FORECAST AND COLLECTIONS
Forecast and Collections
When unpaid invoices are likely to turn into cash, and which customers to chase first. The forecast comes from the trained payment-delay model; the collections queue is a score combining amount, days overdue and predicted delay. The model's accuracy is shown on the Agent Health page.
JD LINKThe role asks for predictive forecasting, work prioritisation and anomaly identification. This page is all three, driven by the trained models and the money at risk.
This page and the Ledger are the same data, seen two ways. The Ledger lists every unpaid invoice. This page takes the invoices still open after the latest reconciliation - part-paid ones at their remaining balance - predicts when each one will be paid, and stacks them into weeks of expected cash - click any week to see the invoices inside it. For each invoice, the model predicts how many days the customer will take to pay, based on that customer's past behaviour, the amount, and the time of year. Sampling many possible payment dates around those predictions gives the weekly P10 / P50 / P90 range - a range a treasurer can plan against, instead of one made-up number. Cash expected after the 8-week horizon is not dropped: it sits in the Beyond row. The collections queue scores each invoice by money at risk: amount, days overdue, and predicted delay combined.
Open receivables
-
Every invoice still open after the latest reconciliation, at its remaining balance
Expected in 30 days
-
Each invoice weighted by its chance of landing in 30 days
Expected in 8 weeks
-
The full horizon, same weighting
At risk
-
Expected beyond 45 days, or under a 50% chance inside the horizon
Cash-in forecast - next 8 weeks
Collections priority queue
Expected cash by customer
What-if - a customer pays earlier or later
Pick a customer and move the slider. The forecast is recomputed from the same model and the same ledger - nothing is saved.
INSIGHT & GOVERNANCE — 09 / POLICY STUDIO
Policy Studio
Governance on the main canvas, not in a drawer: every match the policy held, side by side with the thresholds that held it. Approving a match issues its SAP document, settles its invoices out of the forecast, and generates its settlement mail - in the same moment.
Maker-checker: the solver proved these matches exactly, but policy held them for a second person - most often the amount threshold below, or a partial that needs a human eye. Policy Studio (right) holds the thresholds themselves: save a change and the next run obeys it; preview shows what the change would have done to the active run before you commit.
Policy Studio - thresholds & impact preview
EVALS & ARCHITECTURE — 10 / EVALUATIONS
Evaluations
Three lenses, all computed live. The active case graded against the answer it stated up front; the solver benchmarked against a simple baseline on labelled cases where the correct answer is known; and the ten scenario packs - full pipeline cases, each with its expectations stated before the run.
JD LINKThe role asks for applied data science with results that can be measured. This page measures the solver against answers that were fixed before the run. The delay and validity models are graded on the Agent Health page.
Each test case has a correct answer marked by a human: the invoices the payment truly settles. Both solvers get the same shortlist a real payment would get. Accuracy counts how often the solver's choice equals the marked answer; the exact rate counts answers that leave $0.00 unexplained. The greedy baseline is fast and sounds reasonable, but it fails when the right choice depends on age and deductions together - that is why real payments use the MILP solver. The scenario packs run the whole pipeline (resolution, solver, deduction judgement, policy) on ten stated cases, and every check must pass. The delay and validity models are graded separately, on the Agent Health page, against a held-out test set.
EVALS & ARCHITECTURE — 11 / AGENT HEALTH
Agent Health
Is this deployment healthy, and how good are its models on data they never saw in training? This is the page an engineer or a diligence reviewer asks for.
JD LINKThe role asks for agent health dashboards that prove automation. This page is the proof: live status, model scores and the full audit trail.
The models are trained on synthetic history that contains a real, learnable pattern. They are then graded on later data they never saw (a time-ordered holdout): the delay model's average error against a naive baseline, and the validity model's AUC. What data the models were trained on is printed next to the scores. When real payment history is connected, the same tests retrain and re-grade them. The readiness checks confirm the database, data folder and models are working before the service takes traffic.
Audit trail
Every consequential action in this workspace, in order: runs completed, matches approved or rejected, policy changes. Written by the server at the moment the action happens - it cannot be edited from this interface.
EVALS & ARCHITECTURE — 12 / METHODOLOGY
Methodology
Every formula behind every number in this product, in one place. The API serves this page from the same code that does the calculations. Open any match to see the same formulas with that run's real values filled in.
JD LINKThe role asks for algo-first thinking on NP-hard problems, like Knapsack and MILP. This page shows the exact maths behind every match, in full.
EVALS & ARCHITECTURE — 13 / ARCHITECTURE
Architecture
How the product is built, layer by layer. Each layer names the real technology used in this deployment.
JD LINKThe role asks for system design, distributed-systems thinking, functional programming in Rust and OOP in Python. This page maps each part of the system to the technology that runs it.
Reading this page: the flow is the request path of a single payment, top to bottom. The component table names the module responsible for each stage in the shipped codebase - nothing here is aspirational; the roadmap items are labelled as roadmap on the Product Thinking page, not drawn as if they exist.
Kernel and test suite health
Checked live on this server - the Rust kernel's presence, a live equivalence probe against the Python reference, and the repository suite that CI runs on every push.
Loading live diagnostics...
Built against the Agent Product Builder JD
This product was built for one job description: Agent Product Builder at HighRadius, Hyderabad (job IDs 7734235003 and 7734268003). The table keeps it simple - what the JD asks, where that thing lives in this product, and the tech behind it in one line. The full detail sits on the pages named, working live. Nothing here is a separate demo.
| What the JD asks | Where it lives here | The tech, in one line |
|---|---|---|
| Build autonomous agents for the CFO's office, aiming at 90%+ automation | Run Reconciliation, Dashboard | A pipeline of named steps matches payments on its own; people only see what policy holds back. The automation rate is measured on every run, not claimed. |
| Transform big finance data, LiveCube-style | Upload Center | Files in any layout are mapped to one clean format. Bad rows are listed with the reason, never dropped in silence. |
| Process unstructured data: parsing, matching, reconciliation | Remittance Parser, Run Reconciliation | AI reads the email, a checker verifies every reference against the ledger, then the solver matches the money. |
| Forecasting, work prioritisation, anomaly identification | Forecast and Collections, match evidence | Trained models predict pay dates and build cash-in ranges; z-scores flag strange deductions; every queue is sorted by money at risk. |
| Algo-first thinking: NP-hard problems (Knapsack, MILP) | Methodology, every match's derivation | Matching is written as a MILP with one cash conservation equation and solved exactly with HiGHS, in whole cents. |
| Functional programming, preferably Rust | Architecture (components) | The subset-sum kernel is pure Rust functions, proven equal to the Python solver on 203 shared test cases. |
| OOP in Python | Architecture (components) | The backend is typed domain models, a repository layer and small services, served by FastAPI. |
| System design and distributed systems | Agent Health, this page | One database per tenant, hashed API keys, role-based access, rate limits and health gates. The state of record lives in those databases, not in process memory, so service tasks are interchangeable and can scale out. |
| Agent health dashboards that prove automation | Agent Health, Dashboard, Evaluations | Every number comes from stored runs and live model checks - the proof and the product are the same numbers. |
| Full-lifecycle ownership, PRD to deployment | Product Thinking | PRD, architecture, code, tests, Docker packaging and this live deployment on AWS - all in one repository. |
One JD line is not in this table: the academic record. Software cannot manufacture that, so it is not claimed anywhere in this product. It is answered by the application itself.
Request path of one payment
| Step | Stage | What happens |
|---|---|---|
| 1 | Ingestion + transform | CSV, PDF, image or API input is normalised to the canonical schema: synonym header mapping, source fingerprinting, row quarantine with reasons, OCR on image remittances. Remittance text goes to the parser (Gemini when configured, a deterministic parser otherwise, with the mode shown) and every extracted reference is verified against the open ledger. |
| 2 | Candidate resolution | The ledger narrows down an evidence ladder: exact reference, purchase order, OCR-repaired reference, amount-plus-payer, fuzzy payer name, then the customer's whole ledger. Duplicate wires are fingerprinted (payer, amount, currency) and stopped before matching, and candidates are hard-filtered to the payment's own currency. |
| 3 | MILP solver (HiGHS via scipy) | Subset selection under the cash conservation equality with the age-weighted, penalty-priced objective from the Methodology page. A Rust subset-sum kernel runs inside the solve path: it decides a payment only when its exact set is provably unique (bounded at 18 candidates), and every set the MILP returns is re-verified in exact integer cents before it is believed. Kernel and Python path are equivalence-tested on 203 shared cases. |
| 4 | Deduction intelligence | Claims are classified to the ERP reason taxonomy, z-scored against the payer's own judged claim history in the workspace, and decided by the expected-value dispute rule. Unearned discounts are claimed back as their own reason code. |
| 5 | Posting + exceptions | Exact, confident matches auto-post: their invoices settle and their SAP clearing document is issued in the same moment. Everything else becomes a proposed match (which issues its document on approval) or a tracked exception with counterfactuals. Approving an unmatched wire parks it in suspense with no document at all. All of it lands in the audit log with the run's policy snapshot. |
| 6 | Insight layer | Delay and validity models (scikit-learn, time-ordered holdout) work from the post-reconciliation residual ledger only - settled and part-paid money is never double-counted - and feed the forecast bands (400-simulation Monte Carlo, P10/P50/P90) and the collections queue; the copilot answers only from these stored records. |
Platform components
| Component | Technology |
|---|---|
| API + product UI | FastAPI (Python 3.12); the UI is one page shell plus a stylesheet and four plain-script modules; OpenAPI at /docs |
| Solvers | scipy.optimize.milp (HiGHS) + Rust kernel in the solve path for provably-unique exact sets (equivalence-tested on 203 cases) |
| Data | SQLite (WAL), database-per-tenant isolation; Postgres-compatible schema discipline |
| Tenancy + security | Hashed API keys (shown once), RBAC viewer / analyst / approver / admin, per-key rate limiting |
| Observability | Request IDs, structured JSON logs, Prometheus /metrics, /health and /ready gates |
| AI layer | Gemini extraction and drafting when configured by environment (model and timeout set outside the code); a deterministic fallback otherwise, with the active mode and last error shown on the diagnostics panel - never presented as AI when it is not |
| SMTP when a mailbox is configured; until then every send records as recorded_not_sent with the reason, in the Outbox - a mail is shown as sent only when a server accepted it | |
| Documents + export | The product documentation pack is served in-product from the same files this page links to; the month-end bundle exports as a clean PDF (fpdf2) or raw JSON, generated from stored records |
| Explainers | Every metric on every page carries an info toggle with a three-part explanation (what it is, how it is computed, why it matters) - 139 explanations ship with the UI |
| Packaging | Multi-stage Docker (Rust stage + slim runtime with the test suite and tesseract OCR), non-root, $PORT-aware; deploys to AWS ECS Express |
Design rules that hold the system together
1. AI proposes, math decides. No LLM output can post cash; it can only propose fields that deterministic components verify.
2. Money is integer cents. No floats anywhere near a posting; residuals are exact, never rounding artefacts.
3. Every decision carries its derivation. If a number cannot be recomputed from records the product shows, it is not shown.
4. Exceptions are a workflow, not a failure. The tail is where analysts earn their keep, so it is designed first-class: counterfactuals, recommended actions, audit trail.
5. Policy is configuration. Thresholds that change behaviour live in tenant policy, versioned with each run - never buried in code.
Deployment topology - this exact demo
| Hop | What happens |
|---|---|
| Browser → AWS Application Load Balancer (HTTPS) | The web UI and the JSON API are served by the same container; the load balancer terminates TLS on the *.ecs.ap-south-1.on.aws hostname. |
| ALB → ECS Express task (Fargate, 0.25 vCPU / 1 GB, ap-south-1) | Auto-scaling is capped at 3 tasks as a credit guard. The health-check path is /health; /ready gates traffic on the control database, data directory and models. |
| Container → per-tenant SQLite stores | One database file per tenant under the data directory (container-local in this demo posture, so data resets on redeploy and is re-seeded in one click; the schema discipline is Postgres-compatible for the production path). |
| CI: GitHub push → Actions → ECR → Update service | Every push to main first runs the test gate (146 pytest tests plus the Rust kernel's cargo tests); only a green run builds the multi-stage image and pushes it to ECR, tagged with the commit SHA as well as latest, and the service update rolls it out. Logs stream to CloudWatch; /metrics exposes Prometheus counters. |
Data model
| Table | What it holds |
|---|---|
| tenants / api_keys (control DB) | Tenant registry and SHA-256-hashed API keys with roles. Raw keys are shown once at issue and never stored. |
| invoices / payments (per tenant) | The canonical ledger and the staged payments of the active case - the shared workspace every view reads. |
| runs / run_steps / matches / exceptions | Every batch, its streamed step log, the solver's decisions with full derivations, and the payments the agent refused to settle alone. |
| audit_log | Append-only record of consequential actions: runs, approvals, policy changes, case loads. Entries carry a SHA-256 content fingerprint over their own contents; entries recorded before fingerprints shipped show none. |
| aliases / column_mappings | Learned payer aliases and remembered CSV header mappings per source fingerprint - the transform layer's memory. |
| workspace_meta | The active case: its identity, source, staged expectations for grading, and any case policy override - the record that keeps every page on the same case. |
| tenant_policies | Each tenant's governance thresholds (automation bar, maker-checker limit, tolerances, dispute economics), versioned into every run's snapshot. |
| outbox | Every mail the product composed or sent, with its true status: sent, failed, or recorded_not_sent with the reason. |
Scaling the solver
| Question | Answer |
|---|---|
| Why doesn't the MILP explode? | The solver never sees the ledger. Candidate resolution prunes each payment to a payer-scoped shortlist first (references, PO, OCR-repaired references, amount-plus-payer, fuzzy payer, whole ledger), so the NP-hard core runs on a handful of invoices per payment, not thousands. |
| Raw vs pruned | A 20-invoice pool has 2^20 (about a million) raw subsets; resolution prunes each payment to a short, payer-scoped shortlist first, and HiGHS branch-and-bound closes the rest. The enumeration and kernel fast paths are bounded at 18 candidates, which keeps the worst case small and provable. |
| Latency evidence | Solver time is stored on every match; the Dashboard ribbon averages it for the latest run. The live run streams each payment's solve time as it happens. |
| Equivalence | The Rust kernel and the Python solver are proven identical on 203 shared cases; neither is trusted on its own say-so. |
Where AI plugs in - and where it never does
| Component | Role of AI |
|---|---|
| Remittance parser | Gemini extraction with schema-bound JSON when a server key is configured; deterministic extractor otherwise. Either way, a verifier checks every reference against the ledger before anything is trusted. |
| Copilot | Answers only from the product's own records, with citations. Questions outside the records are refused, not improvised. |
| Delay and validity models | Trained ML (holdout-graded) predicts payment timing and deduction validity; it informs forecasts and triage. It decides nothing about posting. |
| Solver and policy | No AI. Posting decisions are exact mathematics under policy. That separation - AI proposes, math decides - is the product's core safety property. |
| Current status | Which parser runs is set by the server environment, not the code: Gemini when a key and model are configured - as on the live deployment - and the deterministic parser otherwise. Agent Health and the Upload Center always show the active mode, and switching needs no other change. |
EVALS & ARCHITECTURE — 14 / PRODUCT THINKING
Product Thinking
Why SlateMatch is built the way it is - the problem, the design rules, and where it goes next.
JD LINKThe role asks for full-lifecycle ownership - PRD to code to deployment - and first-principles problem solving. This page is that thinking, written in the open.
Success criteria this product would contract on
HighRadius now sells on outcomes, settled against Mutually Agreed Success Criteria. These are the criteria SlateMatch would sign, each measurable inside this product today:
| Criterion | Target | Where it is measured |
|---|---|---|
| Invoice-line touchless rate | Above 80% (top third of the market) | Dashboard impact panel, from stored runs |
| Median market band (Hackett 2025) | 70% auto-match is the market median - the line to beat | Shown beside our measured rate, never blended with it |
| Exception ageing | Every exception carries an owner action the day it appears | Run view exception panel + agent brief |
| Deduction net recovery | Auto-dispute only when proof of delivery is clean and expected recovery clears the $100 minimum; the rest route to an analyst | Dispute desk, expected recovery per claim |
| Cost per remittance | Vendor claim for manual processing is up to $7.82 - automation must cost a fraction | Impact panel hours-returned estimate |
Product thesis
01/
The problem
Cash application is a conservation problem with an information problem on top: every cent received must land somewhere auditable, but the evidence arrives as messy remittance text, short pays and silent deductions. Incumbent platforms advertise 85 to 99 percent auto-match, yet implementations run for months and the exception tail still eats the analyst day. The tail is the product opportunity.
02/
The design rule
AI proposes, math decides. Probabilistic components (LLM parsing, ML delay and validity models) extract and score; deterministic components (the MILP solver under a cash conservation equation, the policy engine, the expected-value dispute rule) make every posting decision. Anything unreconciled becomes a tracked exception with counterfactuals - never a silent write-off.
03/
The wedge
A pilot called the replay: send us your last 90 days of payments and open invoices as CSV. SlateMatch replays them and shows, cent by cent, what would have auto-posted, what would have been disputed, and what your team touched that it should not have had to. Proof before platform.
04/
North-star metric
Touchless cash rate at $0 residual. Supporting: match accuracy on labelled evaluations, residual dollars, exception ageing, dispute recovery value, solver latency.
Roadmap, honestly labelled. Live ERP write-back (SAP, Oracle, NetSuite), bank-file ingestion (BAI2, MT940, lockbox formats), persistent multi-tenant storage, and SOC 2 are the known table-stakes gaps for enterprise sale. This build covers the decision core those integrations feed: matching, deductions, forecast, collections, evaluation and audit.
Honesty labels. All data in this workspace is synthetic and labelled as such. Market figures quoted anywhere in this product are vendor claims used as context, never this product's results. Win probabilities in deduction intelligence are transparent heuristics, and the UI says so where they appear.