Predictive Ledger

Predictive Ledger

This workbook demonstrates how Aito turns accounting software into predictive accounting software.

The 70% → 90% gap: Rules-based automation tops out at ~70%. The remaining 30% is too sparse or contextual to write rules for. Aito fills this gap — without replacing rules.

Dataset: 230 Finnish invoices across 17 vendors, 120 bank transactions, 44 human overrides.

Aito operators used:

• _predict — GL code, approver, vendor matching, anomaly detection
• _relate — rule mining, override pattern discovery
• _match — invoice-to-bank-transaction linking
• _evaluate — prediction accuracy measurement

Instance Activity

Real-time metrics: status, lastRequest, requests5min, memory.

Sample invoices

Interactive query — results displayed as table.

Invoices by vendor

Interactive query — results displayed as chart.

Invoices by GL code

Interactive query — results displayed as chart.

Routing breakdown (rules vs Aito vs human)

Interactive query — results displayed as chart.

How it works

GL Code Prediction

Given a vendor name and amount, Aito predicts the most likely GL code. The $why explanation shows which features drove the prediction.

Try changing the vendor name to see how predictions change.

Predict GL code for Kesko Oyj

Interactive predict — results displayed as table.

Predict GL code for unknown vendor (low confidence)

Interactive predict — results displayed as table.

GL code prediction accuracy

ML evaluation for predict queries.

Predict approver for Kesko Oyj

Interactive predict — results displayed as table.

Predict approver for Kone Oyj

Interactive predict — results displayed as table.

Approver prediction accuracy

ML evaluation for predict queries.

Predict approver for Kesko Oyj

Interactive predict — results displayed as table.

Predict approver for Kone Oyj

Interactive predict — results displayed as table.

Approver prediction accuracy

ML evaluation for predict queries.

How it works

Payment Matching

_predict invoice_id traverses the schema link from bank_transactions to invoices, returning full invoice rows ranked by how well they match the bank transaction.

Aito uses description text tokens and amount as context. When the amount matches training data, it appears as a lift factor in $why.

Try modifying the description and amount to see how predictions change.

Match bank transaction to invoice (with $why)

Interactive predict — results displayed as table.

Telia Finland — amount in $why when it matches training data

Interactive predict — results displayed as table.

Vendor resolution: _predict vendor_name (comparison)

Interactive predict — results displayed as table.

Unknown transfer (should be low confidence)

Interactive predict — results displayed as table.

Browse bank transactions (training data)

Interactive query — results displayed as table.

How it works

Rule Mining

_relate finds statistical relationships between features. For each vendor or category, it shows how strongly it predicts a GL code — with exact support ratios.

Support ratios like 18/18 are exact historical counts, not ML estimates. An accountant can verify each one.

What GL code does category=telecom predict?

Interactive relate — results displayed as table.

What GL code does vendor=Kesko Oyj predict?

Interactive relate — results displayed as table.

Override patterns: which GL corrections cluster?

Interactive relate — results displayed as table.

How it works

Anomaly Detection

Same _predict engine, used in reverse. If Aito is confident about the GL code (high $p), the invoice fits known patterns. If confidence is low, something is unusual — that's the anomaly signal.

No separate anomaly model needed. Compare the two queries below: known vendor vs unknown vendor.

Normal invoice: Kesko Oyj (high confidence = no anomaly)

Interactive predict — results displayed as table.

Anomalous: unknown vendor (low confidence = anomaly)

Interactive predict — results displayed as table.