Straight-through rate
-
OPERATE — 01 / DASHBOARD
Dashboard
What the agent posted on its own, what it would not guess, and what still needs a person - for the one active case in the bar above. Every page in this product works on that same case, and every number here is counted from real runs stored in this workspace.
JD LINKThe role asks for autonomous agents for the CFO's office, with 90%+ automation as the target. This page is that agent's scorecard: every number is counted from real runs, never typed in.
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 Copilot 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. Anything less becomes a proposed match for a person to approve, or an exception with a suggested next step. Nothing is preloaded: a fresh workspace is empty until you load a case.
Unapplied cash in suspense
-
Avg solver latency
-
Invoices settled (last run)
-
Open exceptions (last run)
-
What AutoCash 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.
Touchless rate (last run)
-
Payments posted with no human touch, out of all payments in the run
Approvals waiting
-
Matches in this workspace that policy held for a person
Open invoices
-
Live from the ledger API
Agent mode
-
AI suggests; fixed rules decide. API keys never leave the server.
DASHComponent Guide - Executive 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 — 03 / UPLOAD
Upload Center
Everything enters here: invoice and payment files, and raw remittance emails. Files are mapped automatically; a pasted remittance is read by the AI layer, verified against the ledger, staged into the workspace and reconciled - one front door for the whole agent.
JD LINKThe role asks for LiveCube-style data transformation and for parsing unstructured data. This page is both: files and free-text remittance become clean, verified data here - the Capture Agent's desk.
Reading your file: column names are matched to our fields using a list of known synonyms - for example
inv_no, bill_no and document_no all mean invoice_id. The mapping used is shown to you after import. The file also gets a fingerprint (a hash of its column names) so the same layout is recognised next time. Rows that fail are returned in a quarantine list with the row number and the exact error. Payments are matched immediately, using the current policy, and references are pulled out of the remittance text automatically.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). New invoice IDs are added to the ledger.
Drop invoices CSV here, or click to choose a file
invoice id, customer, amount, PO number, discount %, age, days to due
2. Payments (bank / lockbox)
One row per received payment. On import, every payment is reconciled against the open ledger as a batch run.
Drop payments CSV here, or click to choose a file
payment id, payer, amount, remittance text, optional deduction and reason
Remittance and wire input - the Capture Agent
Step 01 of the agent. Paste any remittance email or wire advice. The parser reads it, the verifier checks every reference against the open ledger, and the verified wire is 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.
Loading workspace...
OPERATE — 04 / RECONCILIATION
Run Reconciliation
The engine matches each payment to invoices. Open any match to see the full evidence for that decision.
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 a known payer alias, then that payer's own invoices. The solver never searches the whole 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
Six named agents, each with its algorithm and the KPI it is judged on - the same way HighRadius prints the algorithm under every agent. 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, Jaro-Winkler fuzzy fallback (0.88) | 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.
Loading the active case...
Matches
Nothing run yet in this view.
Exceptions
Exceptions from the run appear here, each with a recommended action.
Approvals waiting
Matches the agent solved but would not post alone - because policy held them (for example the maker-checker threshold) or a person must sign. Approving posts the match; rejecting returns it to the exception queue. Every decision is written to the audit trail.
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 payer name. 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.
OPERATE — 02 / USE CASES
Use Cases
Ten full working datasets, not toy rows. Each case loads a complete ledger and payment batch into the one shared workspace - so the Dashboard, Ledger, Run, Forecast and Copilot all work on that case - and states its hero payment's correct answer up front, to be graded after the run.
JD LINKThe role asks for agents built from scratch and proven on hard cases. Each case here writes down its correct answer before the run, then grades the run against it.
Each pack is a real portfolio: 16 to 18 open invoices across several enterprise customers, and a batch of 11 to 13 payments of the kind a lockbox delivers in a morning. Inside that ordinary traffic sits one hero payment that exercises the mechanism the pack proves. Load puts the whole dataset into the shared workspace (replacing whatever case was active); run it from Run Reconciliation, and the workspace run is graded field by field against the stated answer - status, auto-post flag, exact invoice set, residual to the cent, deduction decision and ERP reason code. The surrounding traffic is exact referenced wires for other customers, so it can never contaminate the hero payment's candidate pool.
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 - run it from Run Reconciliation and inspect the full derivation on the match. Bring the case you think breaks it.
Loading use cases...
INSIGHT — 05 / LEDGER
Open Ledger
All unpaid invoices the agent can match payments against, with their age and discount terms.
JD LINKThe ledger is the clean, standard data that the JD's transformation requirement produces: one format for every customer and every file.
Invoices arrive through the Upload Center or the demo seed. When a batch uses an invoice, it leaves this list, so it cannot be spent twice. Age matters: the solver prefers settling older invoices first. The discount rate matters: it is the early-payment discount the solver may apply.
Open invoices
-
Across all customers
Open value
-
Gross receivables awaiting cash
Overdue value
-
Due date already passed
Loading ledger...
INSIGHT — 06 / FORECAST
Forecast and Collections
When unpaid invoices are likely to turn into cash, and which customers to chase first. Both come from the trained payment-delay model; its 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.
For each unpaid 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. The collections queue scores each invoice by money at risk: amount, days overdue, and predicted delay combined.
30-day cash-in bands
Loading forecast...
Collections priority queue
Loading...
INSIGHT — 07 / EVALUATIONS
Evaluations
Two lenses, both computed live. First, the active case graded against the answer it stated up front. Second, the solver benchmarked against a simple baseline on labelled cases where the correct answer is known.
JD LINKThe role asks for applied data science with results that can be measured. This page measures the solver and the models against answers that were fixed before the run.
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.
Loading evaluations...
INSIGHT — 08 / 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.
ASSIST — 11 / COPILOT
Copilot
Ask questions about this workspace. Answers come only from the product's own records, each with its source shown - or the copilot says it does not know.
JD LINKThis is the JD's AI requirement used safely: the copilot answers only from the product's own records and shows its sources. It cannot make things up.
The copilot answers only from this product's own records - runs, matches, exceptions, evaluations. It is not free to make things up: every answer shows its sources, questions outside the records are refused, and anything it suggests doing needs a person's confirmation first. Ask why a payment was not matched, and it walks through the same evidence an analyst would check.
Suggested questions - grounded in this workspace's records:
ASSIST — 12 / POLICY
Policy Studio
The rules that control the agent: what it may post alone, what it disputes, and what a person must approve. Change a number here and the next run follows it.
JD LINKPolicy is how one agent serves many companies: the same engine, different rules for each tenant. That is the platform side of the role.
Each tenant (customer company) has its own policy, and the engine loads it fresh on every run - so saving a change here changes what the next run does. The defaults are cautious: an unexplained leftover is the worst outcome, small differences are written off instead of disputed, and anything above the maker-checker limit needs a second person even when the solver is sure.
Loading policy...
INSIGHT — 09 / METHODOLOGY
Methodology - how every number is computed
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.
Loading methodology...
INSIGHT — 10 / 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.
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 API keeps no state in memory, so it 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 or API payload is normalised to the canonical schema: synonym header mapping, source fingerprinting, row quarantine with reasons. Remittance text goes to the parser (Gemini when configured, deterministic otherwise) and every extracted reference is verified against the open ledger. |
| 2 | Candidate resolution | The ledger narrows in order: explicit references, purchase order, payer alias, subsidiary. Duplicates are fingerprinted and stopped before matching. |
| 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 mirrors the combinatorics and is equivalence-tested against the Python path on 203 shared cases. |
| 4 | Deduction intelligence | Claims are classified to the ERP reason taxonomy, z-scored against history, and decided by the expected-value dispute rule. |
| 5 | Posting + exceptions | Exact, confident matches auto-post (simulated posting in this build, labelled as such); everything else becomes a proposed match or a tracked exception with counterfactuals. 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) feed the forecast bands and the collections queue; the copilot answers only from these stored records, with citations. |
Platform components
| Component | Technology |
|---|---|
| API + product UI | FastAPI (Python 3.12), single-file web UI, OpenAPI at /docs |
| Solvers | scipy.optimize.milp (HiGHS) + Rust kernel (optional, equivalence-tested) |
| 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 |
| Packaging | Multi-stage Docker (Rust stage + slim runtime), non-root, $PORT-aware; deploys to Cloud Run or ECS |
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 single-file UI and the JSON API are served by the same container; the ALB 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 builds the multi-stage image (Rust stage, slim non-root runtime) and pushes it to ECR; 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. |
| 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. |
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, alias, payer), 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 typically prunes to under 10 candidates, and HiGHS branch-and-bound closes the rest. The Rust subset-sum kernel mirrors the same combinatorics for the fast path. |
| 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 | This deployment runs the deterministic parser: no Gemini key is configured on the server. Agent Health reports the live mode; adding the key switches extraction to Gemini with no other change. |
ASSIST — 13 / PRODUCT
Product Thinking
Why AutoCash 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 AutoCash 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 | Dispute only when expected value is positive | 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. AutoCash 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.