Accounts Payable

Invoices arrive as documents.They should land as correct entries.

DataTwin takes the invoice from the inbox, reads it, matches it to the purchase order and receipt already in your ERP, runs it through your own control checklist, routes it for approval and posts it, then reads back the journal the ERP created and checks it against the entry it expected. After that it builds the payment run, generates the bank file, and clears the prepaids and provisions before the period ends.

How Discover works
  • Sits above the ERP you already run
  • Read-only until you turn posting on
  • Your approval matrix, unchanged

One invoice, end to end

Three phases, one engine underneath

The invoice lifecycle

Live process

01Invoice to bill

  1. InboxEmail, SFTP, portal
  2. ExtractionEvery field read
  3. MappingVendor, PO, GRN
  4. Matching2-way and 3-way
  5. ValidationRules, tax, cost
  6. ApprovalYour matrix, limits
  7. Post to ERPBill accounted

Journal check: every entry the ERP posts is compared, in real time, against the entry we expected at validation. Differences are raised the same day.

Read-only until you turn posting on — nothing migrates out of your ERP. Every stage runs on the same engine that powers the DARP Framework and FSCP: acquire, process, govern, report.

Invoice to bill, gate by gate

Five checks between a document and an entry

1

Gate 1

It arrives however the vendor chose to send it

Invoices do not turn up in one format. They come as PDFs attached to an email, scans dropped on a shared folder, photographs taken on a phone, one attachment containing three separate invoices, and occasionally something handwritten. The inbox takes all of it, and keeps the original as evidence.

Ingest

One queue, every channel

Mailbox, SFTP, shared folder or vendor upload. One queue, with sender, timestamp and the original kept.

  • Monitored email inbox, with the covering message kept alongside the invoice
  • SFTP and shared-folder collection on a schedule you set
  • Vendor portal upload, so the vendor files it rather than emailing your team

Extraction

Read, not retyped

Header and line-level fields read off the document, from number and date to rate, tax and total. Models tuned to your formats.

  • Multi-page documents and multi-invoice attachments split correctly
  • Multilingual and handwritten documents handled in the same pipeline
  • Every field confidence-scored; low confidence goes to a person, not into the ledger

Hygiene

Duplicates stopped at the door

Before a bill exists, the document is tested against everything already received, by reference, checksum, vendor and amount, or channel.

  • Reference, checksum and near-duplicate matching across entities and periods
  • One invoice arriving by both email and portal recognised as one invoice
  • Documents classified: invoice, credit note, debit note, statement, contract
How the extraction models work
2

Gate 2

It is matched against what your ERP already knows

An invoice on its own is a claim. It becomes a bill when it agrees with something you already committed to. DataTwin reads the open purchase orders, goods receipts, service entry sheets, vendor master and item master out of your ERP, links the invoice to the right ones, and tests them line by line.

Mapping

Linked to the right record

Linked automatically to the vendor, order, receipt, item, contract and entity, wherever the data allows.

  • Vendor resolved from name, tax registration and bank details, not just a quoted code
  • Item resolved from description and classification code where no item code is given
  • The governing contract or agreement attached to the invoice it prices

Matching

Two-way and three-way, by line

Order against receipt against invoice, by line. A total can agree while every line under it is wrong.

  • Two-way for services and expenses, three-way wherever a receipt exists
  • Price, quantity and unit-of-measure variances separated rather than lumped together
  • Tolerances applied by vendor, category or value band, as your policy defines them

Root cause

Classified, not just flagged

Every mismatch is tagged with what caused it, so it routes to whoever can resolve it.

  • Rate error, quantity variance, missing receipt and wrong tax code each tagged distinctly
  • A missing receipt is chased with the receiver, not sent back to the vendor
  • Price differences traced to the contract clause that governs them
3

Gate 3

It is checked against your rules, not generic ones

Matching proves the invoice agrees with the order. Validation proves the bill is right to book. This is where your own internal checklist runs, the one currently living in a spreadsheet, or in the head of the person who has been doing this for eleven years.

Internal checklist

Your own control checklist, run on every transaction rather than a sample, with the result recorded before posting.

Tax validation

Registration confirmed active, rate and calculation re-performed, reverse charge and withholding applied, credit eligibility checked against supplier filings.

Provision reversal

Any existing provision is reversed as the bill is created, and put back with its allocated cost if the bill is cancelled.

Cost allocation

Split across entity, line of business and cost centre by rule or by a driver from the invoice. It reverses with the entry.

Prepaid treatment

The amortisation schedule is built at validation, so month-end releases the right amount without rebuilding it.

Foreign currency

Rate applied under your policy. Differences across invoice, receipt and payment dates are recognised, not absorbed.

Why this matters for gate 5

By the end of validation, DataTwin knows what the entry should be

It holds that entry in full before the ERP posts anything. Nothing is booked because a model felt confident: the entry comes from rules in the schema, so the same invoice always produces the same entry. That is what lets us check the ERP.

4

Gate 4

It goes to the people who should see it

Approval is rarely one step. Different invoices need different people, sometimes in sequence because the second approver needs the first one’s decision, sometimes at the same time because they do not.

Routing

Serial, parallel or both

Routed by value band, cost centre, category, entity or vendor risk, in sequence or in parallel as the case needs.

  • Your existing approval matrix and delegation limits, not a new one
  • Parallel approvals collected at once rather than queued behind each other
  • Out-of-office delegation and escalation after a defined wait

What the approver sees

Context, not a queue

Invoice, order, receipt, variances with causes, checklist result and the entry to be posted. No other system needed.

  • The original document, always one click away
  • Variances explained, not just highlighted
  • The proposed accounting entry, before it exists in the ERP

Human-in-the-loop

One of six control gates

One of six places a person is asked to act. The others: a missing input, a correction, an arbitration, an escalation, a policy fix.

  • Every human decision logged next to the agent action that preceded it
  • Overrides recorded with a reason, and used to improve the rule
  • An accountability trail that reads the same to you and to your auditor
Where a person is always in the loop
5

Gate 5

It posts, and then the posting itself is checked

Approved bills go into the ERP, and the ERP does its own accounting. Almost every AP tool stops there.

Real-time accounting validation

The ERP posts a journal. We already knew what it should say.

DataTwin reads back the journal the ERP created and compares it line by line against the entry it computed at validation. Differences are raised the same day, not at quarter end or by an auditor a year later.

  • Account, cost centre, tax code, currency and amount each tested independently
  • Configuration drift in the ERP surfaced by the entries it starts producing
  • Every comparison retained as evidence, attached to the invoice that started it
The engine underneath this

Bill to payment

Then the money goes out on your terms

A payment run should be decided by due dates and discounts, not by which vendor called this morning. The run is built for you; you decide what leaves.

  1. 1

    Payment sheet

    Built from due dates across every entity and bank. Everything falling due in the window, with what is already overdue separated rather than buried in it.

  2. 2

    Prioritisation

    Early-payment discounts flagged with what each one is worth and the date it expires, so taking a discount becomes a decision rather than a deadline you missed.

  3. 3

    Selection & approval

    You choose what goes out. Disputes and holds are excluded automatically, and the approval workflow runs on the payment run itself, not only on the invoices inside it.

  4. 4

    Payment file

    Generated in the format the receiving bank and payment method require, per entity and per account, with the vendor’s validated bank details rather than whatever was in the last email.

  5. 5

    Payment accounted

    Once the payment is made it goes back to the ERP as an accounted payment, applied against the right bills, and that journal is checked the same way the bill’s was.

Month end

By the time the period ends, most of the close is behind you

Month-end in payables is usually a rebuild: reconstructing prepaid schedules, working out which provisions to reverse, re-cutting allocations in a spreadsheet. None of that is new information; it was all decided when the invoice was validated. So it is done then.

Prepaid amortisation

Scheduled at bill time

Built at validation from the period the invoice covers. Each period releases its slice, and the balance always reconciles.

  • Coverage period read from the invoice or the contract, not keyed by hand
  • Part periods and mid-month starts handled properly
  • Early termination or cancellation adjusts the remaining schedule

Provision management

Raised and released on evidence

Raised where goods arrived without an invoice, reversed when it lands, restored if cancelled. GRNI stops being a balance nobody explains.

  • Provisions driven by receipts and contracts, not a period-end guess
  • Reversal linked to the specific invoice that discharged it
  • Ageing on every open provision, with the reason it is still open

Cost allocation

Applied with the entry

Run as the entry is created rather than a workbook afterwards, and reversed with it. Recharges applied at source.

  • Static rules or drivers taken from the transaction itself
  • Multi-entity recharges applied at source
  • Reversal of the bill reverses the allocation with it
The close runs on this same engine

Vendor portal

The vendor stops emailing your AP team

Most of an AP team’s day is not processing invoices. It is answering two questions: did you get my invoice, and when am I being paid. The portal answers both without a person in the middle, and catches the vendor problems that only surface at payment time.

Onboarding

Validated before they exist

The vendor enters their own details, uploads their registration and bank proof, and is checked before the master record is created, so the problems that normally appear at the first payment appear at onboarding instead.

  • Tax registration confirmed valid and active at source
  • Bank details verified as belonging to the vendor being onboarded
  • Duplicate vendor detection across name, registration and bank account

Invoice submission

Straight into the pipeline

The vendor uploads directly. The document goes into the same extraction and validation pipeline, so a missing mandatory field or a wrong order reference comes back to the vendor immediately rather than three weeks later.

  • Rejected at upload with the reason, not silently held
  • Order reference validated against your open orders as they submit
  • Credit notes and supporting documents attached to the right invoice

Payment status

Answered without a phone call

Every invoice with its current state and what it is waiting on: received, matched, held with the reason, approved, scheduled for a date, paid with a reference. The chase call stops because the answer is already there.

  • Current status and expected payment date on every open invoice
  • Holds shown with the reason and what would clear them
  • Payment references and remittance advice available on completion

Reconciliation

Against a line, not an email chain

The vendor’s statement compared against your ledger, with the differences listed item by item and a conversation thread attached to each one. Disputes get resolved against a specific transaction instead of a forwarded spreadsheet.

  • Statement uploaded and reconciled automatically against your ledger
  • Differences classified: missing, timing, amount, already paid, disputed
  • A thread per difference, with the evidence attached to it
!

Alert on status change

Onboarding checks are a snapshot. If a vendor’s tax registration lapses or their bank details change after they were approved, you are told before the next payment run rather than after the money has left, which is the point at which it stops being an administrative problem.

Under the hood

What is actually doing the work

Specialised agents with narrow, defined duties, coordinated by an orchestration agent, so a new rule or a new jurisdiction is a new agent rather than a rewrite of the pipeline.

Reading the document

Intelligent OCR

One pipeline for PDFs, scans, photographs, multi-page and handwritten. Tuned to your formats, and reading what the transaction is, not just what the fields say.

Applying your policy

Governance Agent

N-way matching by line, your audit checklist on every transaction, root cause on each mismatch. Patterns across vendors surface what precedes fraud.

Correct before it posts

Tax Validation Agent

Registration validated in real time, rates and calculations re-performed, reverse charge applied, and credit eligibility checked against supplier filings before the credit is claimed.

The full agent architectureHow your data is protected

What changes

What changes, honestly stated

Not a longer list of features. A different distribution of who does what, and when a problem is found.

Workload

How AP runs today

Heavy manual effort on entry, validation and chasing exceptions

How it runs on DataTwin

The routine work is automated; your team spends its time on the exceptions that need judgement

Cycle time

How AP runs today

Slow approvals, held up by exceptions and rework

How it runs on DataTwin

Invoice to pay moves at machine speed, with a person involved only where a person is required

Error handling

How AP runs today

Errors detected after the fact, corrected through rework

How it runs on DataTwin

Rules applied before posting, so most errors never get created

Risk

How AP runs today

Fraud and anomalies spotted late, if at all

How it runs on DataTwin

Patterns monitored continuously across vendors, amounts and behaviour

Transparency

How AP runs today

Limited visibility, reporting that arrives after the decision

How it runs on DataTwin

Status on every invoice, with the reason it is where it is

Audit

How AP runs today

Heavy after-the-fact testing, correction long after the event

How it runs on DataTwin

Evidence assembled as the transaction happens, so testing is a read rather than a project

Compliance

How AP runs today

Policy applied inconsistently, with heavy dependence on internal audit

How it runs on DataTwin

The same checks on every transaction, with the result recorded against it

Start here

Before you change anything, find out what it has already cost you

Everything above is prevention; it stops the next one. It does nothing about the last three years, which are sitting in your AP history right now. So we start there, read-only, before there is anything to sign.

2min

This is how long it takes to understand how much can be recovered.

Send us AP history and the vendor master. We test the full transaction population, not a sample, and come back with what is recoverable, split by cash, tax, misstatement and control gaps. Before any contract.

  • AP history
  • Vendor master
  • Full population tested
  • Cash, tax, misstatement, control gaps

Cash back

Duplicate and near-duplicate payments. Paid above contract or order. Quantity paid above quantity received. Credits and advances never recovered.

Tax reclaimable

Credit never claimed, or claimed against suppliers who never filed. Wrong rate or classification. Reverse charge misapplied.

Entries that are wrong

Wrong account, entity or cost centre. Provisions open on invoices long paid. Totals that agree while every line beneath disagrees.

Control gaps

Why the first three keep happening: tolerances nobody set, limits bypassed, bank details changed unchallenged, duplicate vendors.

How Discover works