Banking, Payments & Credit
Invoice Payment Prediction API
The due date on a B2B invoice is a statement of hope. The payment date is a behaviour, and behaviours are predictable.
- Accounting software
- Invoicing platforms
- Receivables finance providers
- ERP vendors
- B2B marketplaces
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Every finance team knows that payment terms describe intentions rather than outcomes. Thirty-day terms produce a payment distribution centred somewhere past forty, with a long tail into ninety and beyond. Some customers pay on a fixed internal run date regardless of your terms. Some pay reliably at day forty-five. Some pay only after the second reminder, every single time.
Collections teams respond by chasing everyone on the same schedule, which wastes effort on customers who were always going to pay on day forty-two and arrives too late for the ones who were drifting. The information needed to target that effort is sitting in the payment history already recorded against each customer, unused.
The prediction problem itself is well behaved. Payment timing is strongly driven by payer identity, invoice size relative to that payer’s normal range, the day of the month the invoice was issued, whether a purchase order reference is present, and whether the invoice has previously been queried. These are stable features, outcomes arrive within weeks, and the model can be retrained continuously on its own resolved predictions.
Who buys this
Accounting software, Invoicing platforms, Receivables finance providers, ERP vendors, B2B marketplaces
What the API returns
What comes back
- Expected payment date per invoice, with a probability distribution rather than a single date
- Probability of payment within terms, and of exceeding thirty, sixty and ninety days
- Payer payment-behaviour profile built from observed history
- Collections priority ranking by expected recovery value and effort
- Recommended action and timing per invoice: no action, reminder, call, escalate
- Portfolio receivables forecast by week, aggregated from invoice-level predictions
- Dispute and query risk flags where the invoice resembles previously disputed ones
- Payer deterioration alerts when behaviour shifts against that payer’s own baseline
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/invoices/predict | Expected payment date and risk for one or many invoices |
| GET | /v1/payers/{id}/profile | Observed payment behaviour profile for one payer |
| GET | /v1/collections/queue | Invoices ranked by collections priority with recommended actions |
| POST | /v1/portfolio/forecast | Expected receivables by week across a portfolio |
| GET | /v1/payers/{id}/alerts | Deterioration alerts against this payer’s own baseline |
| POST | /v1/outcomes | Submit actual payment dates so the model keeps calibrating |
Request and response
illustrativeRequest
{
"invoices": [
{
"invoice_id": "inv_9920411",
"payer_id": "payer_4471",
"amount": { "value": 18400.00, "currency": "EUR" },
"issued_on": "2026-10-02",
"due_on": "2026-11-01",
"terms_days": 30,
"po_reference": null,
"queried": false
}
],
"include": ["distribution", "recommended_action"]
}Response
{
"invoice_id": "inv_9920411",
"expected_payment_date": "2026-11-19",
"days_late_expected": 18,
"distribution": [
{ "bucket": "on_or_before_due", "probability": 0.11 },
{ "bucket": "1_30_days_late", "probability": 0.68 },
{ "bucket": "31_60_days_late", "probability": 0.17 },
{ "bucket": "over_60_days_late","probability": 0.04 }
],
"payer_profile": {
"invoices_observed": 47,
"median_days_to_pay": 44,
"pays_on_fixed_run_date": true,
"typical_run_day_of_month": 19,
"responds_to_reminders": "weakly"
},
"drivers": [
{ "code": "PAYER_FIXED_RUN_DATE", "detail": "Payer settles on or near the 19th" },
{ "code": "NO_PO_REFERENCE", "detail": "Invoices without a PO average 9 days slower for this payer" },
{ "code": "AMOUNT_ABOVE_PAYER_NORM", "detail": "2.4x this payer\u2019s median invoice value" }
],
"recommended_action": {
"action": "send_po_request",
"send_on": "2026-10-24",
"rationale": "Missing PO is the largest controllable delay factor for this payer"
},
"confidence": 0.81
}Where the data comes from
| Your invoice and payment history | Issued invoices with their actual settlement dates — the training label, and the one input that cannot be substituted |
| Payer master records | Payer identity, industry, size and any group relationships, so behaviour is attributed to the right entity |
| Invoice line and reference detail | Purchase order references, approval routing and line structure, which turn out to matter more than most teams expect |
| Collections activity logs | Reminders sent, calls made and responses received, needed to measure whether any chasing actually changes payment timing |
| Dispute and credit-note records | Queried and partially settled invoices, which behave differently and must not pollute the main model |
| Public insolvency and registry filings | Winding-up notices, administration filings and status changes, which are the strongest late-stage non-payment signal available |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Survival models on time-to-payment rather than classification on a late/not-late label, because the question is when and not whether
- Payer-level random effects so a payer with forty observed invoices is modelled on their own behaviour while a new payer borrows from a comparable cohort
- Explicit detection of fixed payment-run behaviour, which dominates the prediction for a large minority of corporate payers and defeats averaging approaches
- Separate treatment of queried and disputed invoices, which follow a different process and would otherwise distort the main distribution
- Causal estimation of collections actions from your own activity logs, so recommendations reflect what measurably changes payment timing rather than what feels diligent
- Calibration monitoring on predicted versus realised payment dates by horizon, retrained continuously as outcomes resolve
- Portfolio aggregation that accounts for correlation between payers, since economic pressure arrives across a sector rather than one customer at a time
- Deterioration detection against each payer’s own baseline rather than a portfolio average, which is how a reliable payer slipping from day forty-four to day sixty gets noticed
What it changes for the business
Targeted collections
Effort concentrates on the invoices where chasing changes the outcome, rather than being spread evenly across the ledger.
Reliable receivables forecasting
Invoice-level predictions aggregate into a weekly cash expectation that a finance team can actually plan against.
Receivables finance pricing
Expected payment date and distribution are the inputs an invoice finance provider needs to price advance rates properly.
Earlier warning
A payer whose behaviour shifts against their own baseline surfaces weeks before the invoice becomes a formal arrears problem.
How it fits into your product
How it embeds
- Predictions computed on invoice creation and refreshed nightly as invoices age and payer behaviour updates
- Collections queue endpoint that slots into your existing workflow tooling rather than requiring a separate console
- Outcome submission so every settled invoice feeds back into calibration without a separate reporting build
- Portfolio forecast output designed to feed a cash flow projection, if you run one alongside
- Per-tenant model isolation for multi-tenant platforms, so one customer’s payment behaviour never informs another’s predictions
- Deployment inside your infrastructure where invoice and payer data cannot leave
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How many invoices do you need per payer?
Around ten settled invoices gives a usable payer-specific prediction; forty gives a good one, including reliable detection of fixed payment-run behaviour. Below ten the model falls back on cohort behaviour and returns lower confidence. It says which regime it is in rather than presenting a cohort estimate as a payer-specific one.
Can you predict insolvency?
No. We can surface the observable precursors — lengthening payment behaviour against the payer’s own baseline, partial payments, new charges registered, public filings — and those genuinely do precede failures. But a healthy business can pay slowly for a year and a failing one can pay on time until the week it stops. Presenting this as insolvency prediction would overstate it badly.
Is this a credit decision?
Not as scoped. It predicts timing on invoices you have already issued. If you intend to use it to decide whether to extend trade credit to a new customer, that is a different product with different obligations around permitted data, explainability and fair treatment, and we would scope it as one rather than quietly repurposing this.
Does one customer’s data improve another’s predictions?
Only if you want it to and only where it is lawful. For most multi-tenant platforms we isolate models per tenant, because pooled payment behaviour across your customers is commercially sensitive to them and in many cases not yours to use. Pooling can improve cold-start accuracy, and if you want it we would want it covered explicitly in your customer terms first.
What happens when the economy turns?
Payment behaviour deteriorates across whole sectors at once, which a model trained on calm conditions will under-predict. We monitor calibration continuously and retrain on recent outcomes, but there is a lag, and during a sharp turn the predictions will be optimistic for a period. That is a real limitation and worth knowing before you build cash planning on top of it.
Related blueprints
Cash Flow Forecasting API
Runway, liquidity and scenario forecasts from transaction and ledger data, embedded in accounting and SME banking products.
Business Verification API
Company registry data, officer and ownership checks and entity resolution, returned as one call your onboarding flow can make.
Transaction Fraud Scoring API
Real-time risk scores for payments and account events, with explanations your analysts and your customers can both understand.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.