Platform

What happens between a file arriving and a recorded decision

Seven stages, six modules, one runtime.

Manuel runs one lifecycle. Every control is the same seven stages with different rules and different data. What you configure happens inside them.

The seven stages

Intake. A file lands on SFTP, an email arrives, an API posts, a database view is read. Manuel registers source, timestamp and checksum, keeps the original, classifies it, splits a file holding several business objects, and extracts each field with its position.

Enrich. Manuel resolves identities against master data, supplier by tax identifier first and by name as a fallback, then attaches the contract version in force on the document date, the rate table, the tax code and the payment terms. Dates, currencies and units are normalised.

Compute. Versioned formulas held as configuration produce the expected value: settlement net of fees, freight cost from the rate card, entitlement against a milestone and a cap, tax and withholding. Each result carries its formula version and its inputs.

Match. Manuel relates the object to the records that should agree with it, in passes, in a stated order, with fallbacks. That is configuration, set out below.

Check. Named rules return true or false: completeness, tolerance, authority limit, duplicate, date sequence, beneficiary risk. An unknown result stops the item. A failed check states the reason.

Resolve. Each object leaves as pass, hold, exception or needs-review. Passing items get the configured action: a posting file, a notification, an approval request, a write-back where granted. Failing items become exceptions.

Record. Every stage records what was read, what was produced, which rule version applied, who acted and when, and the values before and after. Records are retained. A completed run can be replayed step by step.

Record has no module of its own because versioning and audit records apply across the platform.

Six modules, three layers

Later controls reuse the same runtime, approval settings, and records.

The business object

After intake, Manuel works with a business record assembled from the source documents.

A document may run to fourteen pages. One PDF may hold three invoices. A page is a unit of paper. A business object is what the business reasons about: this invoice, this settlement batch, this claim, this trip.

Manuel splits files and assembles each business record. The result includes the values, the location of each value in the source, the matched master records, the calculations, the status of every check, and links to related records.

How matching is configured

Matching follows a written order of rules.

Hierarchy and fallbacks. Passes run strongest key first, each one named. The pass that produced a match is part of the record, so a weak match is visibly weak.

Tolerances. Absolute, percentage, or whichever is greater, set per document type, per counterparty or per amount band. A bank fee band and a contract price band are separate settings.

Date windows. Value date against posting date, within a stated number of days either side. Settlement cycles rarely land on the transaction day.

Cardinality. Manuel matches one to many and many to many: one payment settling forty invoices, one invoice paid in three instalments. The group is held as the matched unit.

Grouping. Where no single line matches, Manuel groups by a stated key, such as merchant and date, and matches the group sum against the target within tolerance.

Residual queues. Items that survive every pass are separated by reason: missing counterpart, outside tolerance, outside the date window, ambiguous candidates, or possible duplicates. The reason determines the owner and priority.

What an exception carries

An exception is a case file with thirteen parts.

1. The failed rule, named and versioned.
2. The expected value, and the formula behind it.
3. The actual value, as received.
4. The variance, absolute and as a percentage.
5. The matching history: passes run, keys tried, what each returned.
6. The related records: purchase order, receipt, contract, statement line, prior payments.
7. The supporting evidence: source document, page, field and its position.
8. The exposure: money at risk, used to order the queue by consequence.
9. The owner: the person or role who can fix this class of case.
10. The next action: the specific step required to resolve the case.
11. The decision history: who did what, when, why, value before and after.
12. The corrective action: what changed, in which system, by whom.
13. The verification result: the recheck after the fix, with both states kept.

All thirteen together is a case somebody can close today.

The exception lifecycle

Detect. A check or a match fails and the object is held. Explain. Manuel assembles the case: rule, expected, actual, variance, match path, records, evidence. Prioritise. The queue orders by exposure, severity and age. Assign. Routing sends the case to the owner of that exception class, escalating as it ages. Resolve. The owner acts, or approves an action Manuel proposes, inside the limits set for their role. Recheck. The same rules run again on the corrected state. Close. The case closes with the records from before and after the fix. Repeated causes can become new rules.

The evidence graph

Every object links back to what produced it. The output row links to the decision; the decision to the rule version and the check result; the check to the expected value and its inputs; the computation to the master data and the contract version in force; the matched pair to the pass and key that produced it; the field to its page and position; the file to its source, arrival time and checksum.

That chain lets somebody repeat a decision months later. Every run produces an evidence pack.

Where AI is used

AI understands, classifies, suggests, investigates and explains. It reads a layout it has not seen before, sorts an unfamiliar case into an existing taxonomy, and proposes a root cause on the residual nobody has encoded yet.

Versioned rules calculate, match, check, decide and record. A tolerance is arithmetic. An authority limit is a rule. A match path follows a stated order. These rules return the same answer when the inputs and version are the same.

Known causes use lookups and formulas. AI is used for cases that still require interpretation.

Who operates it

Operations users work the queues. They see what failed, what was expected, the supporting records, and the next action.

Business process owners configure matching order, tolerances, date windows, calculation rules, evidence requirements, and approval limits. The interface is designed for someone who understands the operation and is comfortable with spreadsheet logic. Configuration changes can be published without a software release.

IT owns the platform standards: identity and role-based access, environments, integration patterns, data handling, and the approval path a change passes before going live. Configured by the business, governed by IT.

What it connects to

Files first: CSV, Excel, fixed-width text, PDF and scans, by upload, shared folder, or SFTP. REST APIs work in both directions. Databases are read through views or replicas. Microsoft 365 email access uses delegated permissions for named users. Screen automation is available when a system offers no other connection.

Where a system cannot be reached from the cloud, we run an on-premise agent inside your network, executing the same configured logic behind your firewall.

Where the product is ahead of the interface

The seven stages and six modules describe how the platform is built. The current interface exposes more technical detail through a canvas of nodes and tasks that our engineers configure during delivery.

We are simplifying that interface so business owners can configure the stages directly.

Related: Security / Solutions / Pre-reconciliation detection