Dantum reads the operational email your finance, operations and maintenance teams work from. It understands the data, extracts it, runs your business process in deterministic code and scores its own certainty. Anything below your threshold goes to a person, with the reason attached.
Every line on an inbound payment schedule is compared against the expected figure held in your own records. Matched lines are posted and closed. Variances outside tolerance are marked and carried into the alert. The arithmetic is ordinary tested code, so the same input always gives the same output.
| Reference | Weekly rate | Periods | Expected | Remitted | Variance | Result | |
|---|---|---|---|---|---|---|---|
| 2 | ACC-100241 | 412.50 | 4 | 1,650.00 | 1,650.00 | 0.00 | MATCH |
| 3 | ACC-100258 | 389.00 | 4 | 1,556.00 | 1,245.80 | −310.20 | MISMATCH |
| 4 | ACC-100263 | 355.75 | 4 | 1,423.00 | 1,423.00 | 0.00 | MATCH |
| 5 | ACC-100279 | 389.83 | 4 | 1,559.32 | 1,559.32 | 0.00 | MATCH |
| 6 | ACC-100284 | 402.15 | 4 | 1,608.60 | 1,608.60 | 0.00 | MATCH |
| 7 | ACC-100291 | 367.40 | 4 | 1,469.60 | — | −1,469.60 | NOT PAID |
| 8 | ACC-100305 | 421.00 | 4 | 1,684.00 | 1,684.00 | 0.00 | MATCH |
| 9 | ACC-100318 | 344.20 | 4 | 1,376.80 | 1,376.80 | 0.00 | MATCH |
People are only contacted about the lines that failed. The alert names the specific reference, the expected figure, the remitted figure and the difference.
The reconciliation for payment run BW-4471 completed. 6 of 8 lines matched and have been posted. Two lines need a decision.
Source message: "Remittance advice BW-4471 — payment run 08/08", received 14 Aug 06:11 from remittances@bridgeway.example. Classified remittance_advice at confidence 0.96.
Open the workbook to see the full comparison, or reply to this alert to raise a query.
Every stage writes what it did, what it decided and how certain it was. This is the record that lets a decision made six months ago still be explained.
06:11:04 INGEST message accepted · sender on allow-list · 1 attachment (xlsx) 06:11:06 ATTACH payment_run_0808.xlsx → private store · shared to service account only 06:11:09 CLASSIFY label=remittance_advice confidence=0.96 threshold=0.80 06:11:09 CLASSIFY rationale="remittance reference and payment date present; attachment is an 8-line payment schedule with per-item amounts" 06:11:11 EXTRACT 8 line items · 6 header fields · schema v3 validated 06:11:11 EXTRACT 2 date fields failed validation → left blank, not inferred 06:11:12 COMPARE deterministic reconciliation · no model involved 06:11:13 COMPARE match=6 mismatch=1 not_paid=1 not_found=0 06:11:13 WRITE 8 rows → Comparison · 6 posted to ledger · 2 held 06:15:02 ALERT 2 exceptions → finance recipient · delivery confirmed 06:15:02 RUN status=SUCCESS stage=done duration=4.1s
When confidence falls below your threshold, or a record can't be resolved with certainty, the pipeline stops and hands the item to a person. It does not guess. The reviewer gets the extracted fields, ranked candidates and a link to the original message, and clears the item in under a minute.
Similarity ranks the list only. It never auto-accepts — near-identical references routinely belong to different records.
Every message passes through the same sequence. The stages are separated on purpose: the language model is confined to reading and structuring, and never touches the arithmetic or the state machine.
The message and its attachments — spreadsheets, PDFs, scans, Word files — are read and classified against a fixed label set you control. The model returns a label, a confidence score and a written rationale. It cannot invent a label outside the schema.
Fields are pulled into a strict, versioned schema: references, dates, amounts, states. A date that does not validate stays blank rather than being guessed. Nothing proceeds on a best guess.
Your process runs in deterministic Python: the reconciliation, the tolerance checks, the legal-transition rules, the record updates.
Anything below threshold, ambiguous or outside the rules goes to the review queue with the fields, the ranked candidates and a link to the source.
Dantum is applied where the input is a mailbox, the work is repetitive, the numbers matter, and a missed message costs real money.
Remittances, statements and payment schedules read out of the inbox and reconciled line by line against your own records.
Records move through defined states as notifications arrive. Nothing sits unnoticed because nobody opened the email.
Documents are read, expiry dates extracted and checked against your register. Alerts name the specific item and separate "overdue" from "no record held", so people do not learn to ignore them.
Dantum is one platform with a configuration for each customer. Onboarding sets up yours, flags the gaps in your process that automation would amplify, and proves the output against your own before anything goes live.
Scoped access to the mailboxes you choose. Dantum profiles a sample of real inbound mail: what arrives, from whom, in what shape and how often.
Your label set, extraction schema, tolerances and state rules live in your client profile. The platform is shared; the rules are yours.
Ambiguous states, missing identifiers and rules that contradict each other are flagged and settled before go-live, so automation does not amplify them.
The pipeline runs alongside your team until its output agrees with yours. Only then does it take over, and the manual route stays available.
Every customer runs on the same platform under the same model. What you pay depends on how many mailboxes you connect and how much mail flows through them.
Connecting your mailboxes, configuring your client profile and the shadow run that proves the output before go-live.
The pipeline, the review queue, exception alerts, the audit log and UK data residency, priced by connected mailboxes and monthly volume.
Add mailboxes, processes or teams as you grow. They join the same subscription rather than starting a new project.
For a quote, email sales@dantum.ai with the mailbox the work arrives in and a rough monthly volume.
Dantum runs on Google Cloud in the UK region.
Access is restricted to the specific mailboxes agreed with you, enforced at the identity-provider level.
An allow-list you maintain governs which senders are processed. If it cannot be read, the run halts rather than processing unvetted mail.
No long-lived API keys in the service. Credentials are short-lived and issued at runtime; secrets are stored securely.
Documents are held in private storage shared only with the processing service account, and deleted on a short retention timer.
Every classification, extraction, comparison, alert and human resolution is logged with its inputs, its confidence and its outcome.
Manually edited fields are never overwritten by the pipeline.
Tell us which mailbox the work arrives in and what happens to it now. We will check a sample and tell you honestly whether Dantum handles it.