Predictive ERP on Aito

Turn Your ERP into a Predictive Application

A predictive application is an operational SaaS where the data layer doesn't just store transactions — it predicts the next one. Predictive ERP means purchase orders that route themselves, smart-entry forms where four fields fill in from one supplier pick, anomaly detection that flags miscoded accounts before posting, and demand forecasts that drive replenishment without a separate model.

Aito is the predictive database underneath. Every prediction comes back with a probability, top-3 alternatives, and a $why factor decomposition. No retraining, no MLOps, no separate ML pipeline alongside your ERP transaction tables.

Live Reference: erp.aito.ai

erp.aito.ai is our open-source reference implementation of a predictive ERP — 19 production-ready views built on _predict, _relate, _estimate, _evaluate, and _search. The same code powers three industry profiles (industrial maintenance, multi-channel retail, professional services), each with its own Aito database and persona-appropriate fixtures.

Explore the Use Cases →  ·  Try the Live Demo →  ·  Source on GitHub →

What's Inside the Predictive ERP Reference

Procurement & approvals

• 📋 PO Queue — Each purchase order arrives with predicted account code, cost center, and approver, sorted into Rule, Aito and Review rows (review when the weakest field is below 0.75); the coding on Rule and Aito rows can be accepted in bulk, while authorising the spend stays with the approver.
• ✨ Smart Entry — Multi-field prediction with cross-highlight: pick a supplier and four fields predict in parallel (cost center, account code, project, approver). Tab to accept, Esc to reject.
• ✅ Approval Routing — _predict of the approver and the approval level from supplier and category, with fixed escalation rules on top: security over €5K → CFO, capex over €20K or anything over €50K → Board.
• ⚠️ Anomaly Detection — Inverse prediction: low confidence on a normally-predictable field is the anomaly. Three types: amount-spike, unknown-vendor, mis-coded-account.

Supplier, catalog & pricing intelligence

• 🏭 Supplier Intel — Spend leaderboard plus delivery-risk discovery via _relate — "Neste: 31 of 477 deliveries late, 6.5%, against 4.9% across all suppliers".
• ⚙️ Rule Mining — Discover statistical patterns with support and lift, promote with audit trail, dismiss to record the decision so it doesn't resurface.
• 📦 Catalog Intelligence — Multi-field gap-filling on workflow-blocking products: predict category, HS code, unit price one-shot across the catalog.
• 💰 Price Intelligence — Each incoming quote scored by _estimate unit_price over earlier prices only, beside the product's own median; quotes more than 15% above the estimate are flagged.

Demand, inventory & projects

• 📈 Demand Forecast — _estimate units_sold from the season and last year's same-month sales, measured on six held-out months: 15–42% less error than the trailing-average reorder rule, roughly on par with same month last year.
• 🏗 Inventory Intelligence — Days of cover and stockout risk per item: does stock on hand plus what is on order cover demand until the next delivery? Asked with Aito's forecast and with the trailing-average reorder rule, and checked against the held-out months.
• 🗂 Project Portfolio — _predict of six outcomes per active project, plus a combined reading from outcome_score, each with $why; a success-factors panel ranks the properties of the work (never people) that move each outcome, via _relate.
• 👥 Utilization & Capacity — Per-consultant load with role forecasting via _predict allocation_pct (services tenant).

Cross-cutting

• 🛍 Recommendations — Bought together: _relate lift over order baskets, with the counts behind each pair (retail tenant).
• 📊 Automation Overview — held-out accuracy per field against the most-common-value baseline, measured calibration by confidence band, and a month-by-month learning curve computed live from routed_by × order_month.

Every view ships with a hero screenshot, working code, and a use-case guide. Same operators across all 19 features — _predict, _relate, _estimate, _evaluate, _search.

How Much Can You Automate? (The Honest Answer)

Two things are true at once.

The verifiable facts. Industry-wide, automated AP error rates land below 0.8% when properly configured; best-in-class AP teams hit 60-80% touchless processing rates and 3–5-day cycle times. Aito has run AP automation at 95%+ accuracy in Nordic enterprise production since 2018, on the same predictive operators. PO-backed invoices typically auto-match at 60-80% via three-way matching before any prediction is needed; predictions earn their keep on non-PO invoices, where even a small share can break a manual-coding workflow.

The conditional answer. All ERP procurement processes are super-regular at their core — procurement contracts, BOMs, scheduled-maintenance cycles, and accounting consistency rules see to that. What differs between customers is how much of your incoming PO volume matches prior patterns vs. arrives as a first-time pattern. Predictive ERP is a conditional-probability engine that works the same way on each transaction; how many of your transactions benefit from it depends on the volume mix.

Why ERP transaction data is unusually predictable to begin with

Procurement and ERP transactions are more regular than typical ML training data because of how the underlying business operates. Procurement contracts lock supplier-account mappings. BOMs and SKU taxonomies are stable across years. Maintenance schedules repeat on calendar cycles. And GAAP/IFRS accounting consistency rules apply once those POs flow into the GL. The same supplier × category combination maps to the same cost center 95%+ of the time, not by coincidence but by operational and regulatory design.

This is why on regular procurement data a supplier's pattern becomes predictable after a handful of POs; how many depends on how consistent the supplier is, so measure it on your own history with _evaluate rather than assume a fixed count. The top confidence bucket (>95%) carries near-zero realized error in production — Aito's confidence is calibrated, so when it says >95%, the realized rate matches.

Three pattern-repetition profiles, three different ranges

Underneath all three, the process is the same — same coding logic, same conditional-probability math, same calibrated confidence. What changes between deployments is the volume mix: how much of the incoming PO stream lands on patterns already seen many times vs. arrives as a first-time pattern.

The conditional-probability machinery is the same across all three profiles. The confidence a pattern earns depends on how consistent it is, not on the profile. What differs is how many of your incoming POs land on patterns already seen vs. arrive as novel ones.

Find your profile in 15 minutes: run _evaluate on a held-out slice of your real data. Per-field accuracy and per-confidence-bucket calibration tell you which range your tenants sit in.

How quickly a pattern earns its confidence

Where contractual and operational stability apply, ERP transaction data isn't noisy. The same supplier × category maps to the same cost center 95%+ of the time. The conditional probability collapses fast because there's not much disagreement to average over.

How many POs a supplier needs before its confidence is earned depends on how consistent that supplier is, so it is a number to measure, not to assume. On the ERP demo's synthetic data (Metsä profile), _evaluate on 200 held-out POs predicts the cost center right 96.0% of the time against a 34% base rate, the account code 93.5% against 25%, and the approver 88.5% against 31.5%. Run the same check on your own history, per field and per confidence bucket.

Not every field is equally stable, even on regular workloads

A subtle but important distinction: even when the workload is regular, not every field is equally stable. The split tells you which predictions need to be more reactive to recent overrides.

Two practical implications: (a) person-keyed predictions need to be more reactive to recent overrides than account-keyed predictions — handled naturally because every override is the next prediction's training signal; (b) chart-of-accounts reorganizations and supplier-master changes are documented events, so a brief drop in account-keyed accuracy after a reorg is expected and recoverable as the new mapping accumulates.

The snowflake tail and what still works there

ERP procurement always has a long tail. One-off subcontractors on a specific build project, exceptional ad-hoc purchases, employee-expense passthroughs in services workloads, equipment rentals from a supplier seen once — statistical snowflakes by construction. No amount of data resolves them.

The honest answer: supplier-keyed predictions don't work on the snowflake tail. A supplier seen for the first time has zero conditional history. Aito returns honest low confidence, not a wrong high-confidence answer.

What still works on snowflake POs

Different prediction targets depend on different signals. Not every field is supplier-locked:

Smart Entry on a snowflake PO doesn't return blank fields. It returns field-level predictions with field-level confidence, with $why rendered so the reviewer sees what was used. The fields that repeat auto-fill; the supplier-locked fields surface for human judgement.

What production actually looks like — two anchor points

Anchor 1 — recurring industrial procurement ("highly regular"). A workload dominated by recurring supplier POs against a stable category catalog — spare-parts replenishment, scheduled maintenance procurement, recurring utility/network suppliers — looks like:

• ~80%+ fully automated at the high-confidence threshold, realized error near zero.
• ~15-20% reviewed-with-prefill — mostly the medium-confidence tail.
• ~0-5% mostly manual — the actual one-off long tail.

Anchor 2 — heavy snowflake tail ("highly diverse"). A predictive ERP workload with significant project-subcontractor or ad-hoc spend splits roughly into thirds:

• ~1/3 fully automated. Top confidence bucket. Realized errors essentially zero — Aito's confidence is calibrated.
• ~1/3 reviewed but pre-filled. Mid-confidence across most fields. Reviewer confirms instead of types — 4-5× speedup over manual coding.
• ~1/3 partially filled, mostly manual. Snowflake POs where supplier-locked fields are unknowns. Even here, category, approver, and project are usually pre-filled with $why rendered, so the human judges 1-2 fields, not all 5.

Both are real production observations. Most products serve a mix of tenant shapes and land between the two anchors.

Buyer diligence: run _evaluate per field

The single best 15-minute test is to run _evaluate on a held-out slice of your real data. Pay attention to two things:

1. Per-field accuracy. Description-keyed fields (category, project) typically hit 90%+ even on diverse workloads; supplier-locked fields drop sharply on the snowflake tail.
2. Per-confidence-bucket calibration. The top bucket should land at near-zero realized error if the model is well-calibrated. If it doesn't, your tiered-confidence UI plan won't work.

Your UI keys off field-level confidence per prediction: auto-fill the high-confidence fields, suggest the medium, route the low to human review with $why. Cold-start handles itself field by field, confidence-bucket by confidence-bucket.

The drift ceiling, honestly

Per-field accuracy on the recurring core caps around 92-95% from drift (supplier account changes, taxonomy shifts, org reorgs, personnel changes for person-keyed fields). Per-field accuracy on the snowflake tail caps lower; that ceiling is structural. Tenant-wide headline accuracy is the volume-weighted blend.

A predictive ERP product covering tenants with heavier snowflake shares will see lower headline accuracy — that's the data, not the model. Both numbers are correct, and both are useful, as long as your UI is field-level confidence-aware.

Pick your closest fixture profile to bootstrap

The reference ships three: Metsä Machinery (industrial maintenance — heavy recurring core), Aurora Retail (multi-channel commerce — mixed), Vire Consulting (professional services — heavier passthrough tail). Each is its own Aito DB with 3-5K POs of persona-appropriate data. Switch tenants in the TopBar and the predictions retone — and the recurring/snowflake split shifts visibly. Your real product points Aito at your tenants' data; the same code path serves them all.

The Override → Learn Loop (Why You Don't Need MLOps)

User changes a predicted cost center from 4220 to 4210 at 14:00:23. The next request for a similar PO — different PO, same supplier, same description — reflects the new pattern in its conditional probability. No retrain queue. No model deploy. No A/B holdout.

This is why predictive ERP scales differently than traditional procurement automation. Rules rot; predictions improve with every override.

The End-to-End Workflow Loop

The signature interaction in a predictive ERP is the loop: Smart Entry submits → PO Queue picks it up → Approval Routing predicts the approver. Every override trains the next prediction.

That's the whole demo in one screenshot: pick a supplier, four fields predict, click submit, watch it route. No retraining between steps, no model deployment after a correction.

Try Live ERP Predictions

Run the same predictions used by erp.aito.ai directly from this page. These queries hit our hosted demo database — no signup, no setup.

{
  "from": "purchases",
  "where": {
    "supplier": "Lindström Oy",
    "description": "Workwear order"
  },
  "predict": "cost_center",
  "select": [
    "$p",
    "feature",
    "$why"
  ]
}

Three Industry Profiles, One Predictive Database

The same predictive ERP code drives three personas, each with its own Aito DB and persona-appropriate fixtures:

Each profile filters which views appear in the side nav. The right-rail Aito panel re-tones with persona-specific examples: Metsä's panel quotes Wärtsilä → account 4220; Aurora's quotes Valio → account 4010; Studio's quotes Adobe → account 5530. Switch tenants in the TopBar — same code, different conditional probability distribution.

Three Signature Interaction Patterns

Three small, reusable components carry the predictive-application UX. Anyone porting this pattern to another vertical should keep them.

PredictionExplanation — the $why renderer

Pure component that turns Aito's $why factor tree into:

1. Prediction value + confidence bar
2. Base rate (baseP)
3. Top 3-5 pattern matches with token-level highlighting
4. The multiplicative chain baseP × lift₁ × lift₂ × … = finalP
5. Top 2-3 alternatives, clickable to override

WhyPopover — confidence-aware ledger annotation

A ? / ! button anchored to a row that opens a popover. Visual prominence scales inversely with confidence — faint at ≥85%, gold at 50-85%, pulsing red ! at <50%.

SmartField — three-state input

Single DOM input that's the same field whether the value came from a prediction or the user. Three visual states: empty / predicted (gold-italic with 🤖 badge) / user (normal). Tab promotes, Esc rejects, typing replaces.

These match the patterns in the smart form fill use case and the $why explanations in the API docs.

Predictive ERP vs. Traditional Procurement Automation

Traditional procurement automation means: write a routing rule, write a coding rule, write an approval rule, write an anomaly rule. Maintain them. Watch them rot. Hire people to clean up the 70% that doesn't fit.

A predictive ERP flips it: load your transactions, query for predictions, promote patterns to rules with governance. No retraining, no MLOps, no feature engineering. The data is the model.

Technical Implementation

Simple API Integration

Every predictive ERP feature reduces to a SQL-like JSON query:

{
  "from": "purchases",
  "where": {
    "supplier": "Wärtsilä Components",
    "description": "Hydraulic seals #WS-442",
    "amount_eur": 4220
  },
  "predict": "cost_center",
  "select": ["$p", "feature", "$why"]
}

Response in ~30 ms with the prediction, confidence, top-3 alternatives, and the full factor decomposition.

Aito Operators Used

Schema Evolution Without Migration

ERP schemas change. Tenants add custom fields, redefine cost-center taxonomies, split SKUs, introduce new GL accounts mid-year. In a typical ML pipeline, every schema change triggers a migration ticket: update the feature pipeline, re-extract features, retrain, redeploy.

In Aito: add a column, the next prediction reflects it. No migration step, no retraining trigger. Aito stores rows as semi-structured documents; the next _predict query that includes the new field uses it as another conditional in the probability calculation. Existing queries that don't reference it are unaffected.

This is what makes Aito viable for a 10-year ERP product. You can't ship a long-lived product on top of a feature pipeline that needs schema-coordination on every customer's chart-of-accounts change.

Multi-Entity, Multi-Currency in Production

The reference demo runs three single-entity profiles. Production customers handle multi-entity in one of three patterns:

• One Aito DB per legal entity. Cleanest isolation; predictions never cross entity boundaries. Right when entities have different charts of accounts, different approval hierarchies, or different statutory requirements. Cost: one Aito plan per entity.
• One DB with entity_id in where. Same predictive database, conditional probability scoped per entity in the query. Right when entities share a chart of accounts but want predictions to learn from each other (e.g., subsidiaries of the same group). Same multi-tenant pattern as customer_id for SaaS.
• Hybrid: federated DBs + cross-entity _evaluate. Per-entity Aito DBs for prediction, plus a roll-up DB that ingests all entities' transactions for cross-entity rule mining and group-level benchmarking. Right when group analytics matters but entity-level isolation is required for SOX or statutory reasons.

For multi-currency: store amounts in the transaction currency plus a normalized base currency (EUR, USD, etc.). Predict against the normalized field; display in the original. Aito's conditional probability doesn't care about units, but consistency in the column matters.

What's Intentionally Out of Scope

The reference implementation owns its gaps. Three-way matching, GL period control, multi-country chart of accounts, segregation of duties, multi-entity / multi-currency, audit trail persistence, schema evolution, multi-worker cache coherence, p99 load testing, e-Invoice generation — these are real ERP concerns, intentionally not in the demo. Each one is documented in the README's "What this demo does NOT show" section with the production path forward.

Prove It on Your Data in 15 Minutes

The fastest way to disqualify Aito for your ERP use case is to run _evaluate on a slice of your real transactions.

1. Export 1,000-10,000 POs (or sales orders, journal entries, work orders) as CSV — supplier/customer, amount, description, the field you'd predict, and any context columns.
2. Upload to a free Aito sandbox.
3. Run _evaluate on a held-out slice. Get per-class accuracy, top-3 accuracy, confusion matrix, and a baseline-vs-Aito diff.
4. Compare to always-predict-majority and to whatever rule set you have today.

If the lift is convincing, schedule a technical review. If not, an afternoon saved a procurement cycle.

Build vs. Buy: The Honest Math

For a 5-15 person product team building a predictive ERP SaaS:

Build it yourself. A working prediction loop with multi-tenancy, retraining, evaluation, and override capture takes ~6 months and ~1.5 FTEs (one ML engineer, ~0.5 backend for plumbing). At €100-130K loaded ML salary plus infrastructure: year-1 TCO €200-400K, year-2 €120-200K maintenance. Plus you're operating retraining infrastructure in production.

Drop in Aito. API key and SQL-like queries, 1-2 weeks to a working prediction loop. Multi-tenancy is customer_id (or tenant_id) in the where clause. Aito plans start at €0 (sandbox), €75/mo (small production), €350/mo (growth) — see pricing. You give up some control over model internals; you gain ~5 months of engineering and the right to delete user data without a model-retraining ticket.

The breakeven question. Time to first paying tenant matters more than build-vs-buy purity. Six months later means six months less revenue and a smaller dataset to learn from when you do ship.

Throughput & Sizing Per Plan

Latency is per-prediction (~30 ms typical). Throughput is what you provision for, and Aito plans differ by API-call quota and storage:

Worked example. A predictive ERP SaaS with 200 tenants averaging 50 POs/day each = 10K POs/day. Each PO triggers ~5 predictions (cost center, account, approver, project, anomaly check) = 50K predictions/day. Add Smart Entry (4 predictions per supplier-pick, ~20K supplier-picks/day) = ~130K predictions/day. Comfortable on Prod (€350/mo, unlimited). Storage at ~10K rows per tenant fits 1GB at this stage; extends as you grow.

For multi-tenant SaaS beyond ~500 tenants or multi-entity ERP groups, contact us — Enterprise pricing is per-instance with dedicated infrastructure. Nordic enterprise AP workloads have run at this tier since 2018.

How This Compares: SAP Joule, Oracle AI, GPT-4 + a Vector DB

The four honest alternatives we hear:

vs. SAP Joule / Oracle Adaptive Intelligence / NetSuite SuiteAnalytics. These are bundled with the underlying ERP — great if you're already there, locked in if you're not. They don't help you build a new predictive ERP product. Aito is the substrate for vendors building one.

vs. GPT-4 + a vector database for procurement. LLMs reason well over unstructured input but cost ~1-3 sec per call, are opaque (no $why), and don't learn from corrections. For volumetric ERP work — thousands of POs/day per tenant — the unit economics break. Use LLMs for free-form supplier-message classification, Aito for the structured prediction.

vs. building it on scikit-learn / Vertex AI / SageMaker. You can. You'll spend the 6 months above. The thing you build is a worse predictive database with retraining infra you operate.

vs. RPA-based procurement automation (UiPath / Blue Prism with rule scripts). Rules cover only what someone wrote a rule for, and rot. Aito routes high-confidence rows automatically and honestly flags the rest. Most predictive-ERP customers run UiPath and Aito — RPA for the deterministic plumbing, Aito for the decisions.

Security, Compliance & Data Residency

• EU data residency by default. Hosted in AWS Frankfurt (eu-central-1). US deployment on request.
• Encryption. TLS 1.2+ in transit; AES-256 at rest.
• Tenant isolation. Per-customer Aito instances by default; shared multi-tenant pattern is opt-in.
• DPA. GDPR-aligned Data Processing Agreement on request.
• Audit logging. Every API call logged with timestamp, key ID, query, and response time.
• Right to be forgotten. No model artifact derived from user data — DELETE the rows and predictions reflect it from the next query forward.

We do not currently hold a SOC 2 Type II attestation; we share our security posture and pen-test results under NDA. For procurement that requires SOC 2 today, contact us — we work with regulated-finance customers under DPA + security questionnaire.

Platform Stability & Long-Term Commitment

ERPs ship for 10+ years. Before you bet a product roadmap on Aito, the questions you should ask:

• API stability. The core query API (_predict, _relate, _search, _recommend, _evaluate, _match) dates from the public v1 release in 2019. We version at the API level, and behavior changes are listed in the changelog.
• Deprecation policy. Minimum 12 months notice before any deprecation. Migration guides published with each.
• Operating history. Aito has run in production since 2018 across multiple corporate owners — Nordic enterprise AP deployments processing thousands of invoices per month at 95%+ accuracy. See About for the current corporate posture.
• Source of truth, not lock-in. Your data goes in via standard JSON. It comes out via _search. There is no proprietary format you can't export. Worst case migration: read your rows, write them somewhere else.
• Open-source reference implementations. The accounting and ERP reference apps are Apache 2.0. If our company posture changes, the patterns we taught remain yours to operate.

For the company posture, funding, and team behind Aito — see About or contact us for current details under NDA. Multi-year procurement reviews welcome.

Where Predictive ERP Fits

For ERP SaaS vendors — bake predictions into your product. Smart Entry, anomaly flags, and approval routing become default features instead of premium add-ons.

For ERP integrators — bolt a predictive layer onto an existing customer install. Aito sits alongside SAP / Oscar / Lemonsoft / NetSuite as a prediction service called via API. See the accounting solutions page for the AP-automation pattern.

For internal IT — augment your ERP UI with predicted fields without going through the model-training-and-deployment cycle. Add a row, the next prediction reflects it.

Get Started Today

Ready to ship a predictive ERP — or add predictive features to one you already operate?

Try erp.aito.ai → — see what 19 predictive ERP views look like across three industry profiles.

Read the source on GitHub → — Apache 2.0, 19 use-case guides, three-tenant reference architecture.

Schedule a Demo — walk through your specific ERP automation use cases with our team.

Start Free Trial — point Aito at your own transaction data in our sandbox environment.

Why we built all of these on one substrate

Predictive Accounting, Predictive ERP, and Predictive E-commerce are not three separate products. They are three instances of the same pattern: a SaaS application designed around the premise that the user should never make a decision the data has already made for them. The substrate is a predictive database. Prediction becomes a query rather than a project.

For the full architectural argument, see The Predictive Application. The canonical explanation of why per-prediction cost determines what gets built, and what changes when that cost collapses.