P2PPurchasing and payables

Match the invoice to the order and the goods that arrived.

Two-way and three-way matching with the tolerance you set per field, so a rounding difference is not a pricing dispute. Receipts accumulate against one order across as many deliveries as it takes.

Request a pilot What it does not do yet

What it does

Built to produce a verdict, not a to-do list.

Order, receipt and invoice matched line by line.

Two-way and three-way matching with per-field tolerances, so a rounding difference is not a pricing dispute
Cumulative receipt tracking against one order, across as many deliveries as it takes
A configurable multi-step approval chain by value band, with approve, reject and send-back all recorded with a reason

app.docinflow.ai

Procure-to-Pay in DocInflow

What it actually does, step by step.

Each stage below is a real part of the product, not a category. The counts come from the configuration the product ships with.

purchasing flow shapes, derived from the documents you upload

5 · 4

comparison modes, and methods for pairing invoice lines to order lines

exception filters, each one bookmarkable

Link the documents, whichever arrives first

Five purchasing shapes derived from what is present — invoice to order, to receipt, or both
A purchase order uploaded after its invoices still pulls them in
Duplicate order, invoice or receipt numbers caught before a second payable can form
An invoice authorised by a contract rather than an order sits in the same list

Pair the lines, not just the totals

Exact item code first, then a normalised form, then fuzzy description
“EC-200” meets “ec 200” without anyone editing a master
The method that won and how confident it was are recorded on every row
Missing columns are handled gracefully instead of raising noise

Compare under your own tolerances

Five modes per rule — exact, tolerance, contains, normalised, fuzzy
Per-rule tolerances override the organisation default, on headers and on lines
Three fuzzy thresholds: 0.80 by default, 0.70 for names, 0.55 for clauses
A failing value is re-tested against your tax regime before it is flagged

Track one order across many deliveries

Opt one order in; quantity and total relax while unit price stays strict
Ordered, received and invoiced roll up with outstanding quantity and value
Bill ahead of receipt freely — bill beyond it and we escalate immediately
Credit and debit notes net the invoice before it is compared, not after

Work the exceptions, not the list

A financial mismatch is scored heavier than a logistical one
Escalation on a variance percentage or an absolute amount, in the document's currency
Seven exception filters, held in the URL so a view can be sent to someone
Any line can be accepted, flagged or disputed, with a name and a time on it

Pay once, and record who said so

One payment instruction per invoice, enforced by a unique constraint
Payment state rolls up: paid, partially paid, due, pending review
Marked paid by a person, by a posted payment, or by your own system over the API
An invoice naming an unknown vendor gets a one-click fix, not a dead end

Link the documents, whichever arrives first

Five purchasing shapes derived from what is present — invoice to order, to receipt, or both
A purchase order uploaded after its invoices still pulls them in
Duplicate order, invoice or receipt numbers caught before a second payable can form
An invoice authorised by a contract rather than an order sits in the same list

Pair the lines, not just the totals

Exact item code first, then a normalised form, then fuzzy description
“EC-200” meets “ec 200” without anyone editing a master
The method that won and how confident it was are recorded on every row
Missing columns are handled gracefully instead of raising noise

Compare under your own tolerances

Five modes per rule — exact, tolerance, contains, normalised, fuzzy
Per-rule tolerances override the organisation default, on headers and on lines
Three fuzzy thresholds: 0.80 by default, 0.70 for names, 0.55 for clauses
A failing value is re-tested against your tax regime before it is flagged

Track one order across many deliveries

Opt one order in; quantity and total relax while unit price stays strict
Ordered, received and invoiced roll up with outstanding quantity and value
Bill ahead of receipt freely — bill beyond it and we escalate immediately
Credit and debit notes net the invoice before it is compared, not after

Work the exceptions, not the list

A financial mismatch is scored heavier than a logistical one
Escalation on a variance percentage or an absolute amount, in the document's currency
Seven exception filters, held in the URL so a view can be sent to someone
Any line can be accepted, flagged or disputed, with a name and a time on it

Pay once, and record who said so

One payment instruction per invoice, enforced by a unique constraint
Payment state rolls up: paid, partially paid, due, pending review
Marked paid by a person, by a posted payment, or by your own system over the API
An invoice naming an unknown vendor gets a one-click fix, not a dead end

Scroll sideways for the rest of the flow.

The cheapest invoice to fix is the one you have not paid yet.

A rate that drifted, a delivery that came up short — both are recoverable before payment and awkward conversations afterwards.

Core capabilities

Strengthen your purchasing end to end

Every invoice finds its paperwork, however it arrives

Five purchasing shapes are derived from what you upload rather than fixed in advance — invoice to order, invoice to order to receipt, invoice to receipt, order to proforma, contract to invoice. Anything unusual becomes its own flow rather than being forced into a shape that does not fit it.

└─A purchase order that arrives after its invoices still pulls them in
└─An invoice authorised by a contract rather than an order sits in the same queue
└─Duplicate numbers are caught before a second payable can form

It reads your line items the way your buyer does

Row pairing cascades through exact item code, a normalised form that strips spaces and dashes, and fuzzy description matching with a floor of 0.85, recording which method won and how confident it was on every row.

└─“EC-200” meets “ec 200” without anyone editing a master
└─“PALHARI CHIWDA 200” meets “PALHARI CHIWDA 200GM M-47”
└─A row that could not be paired is flagged, never passed silently

One order, ten deliveries, no false alarms

Opt a purchase order into partial fulfilment and quantity and total become a cumulative ledger — ordered, received and invoiced, with outstanding quantity and value — while unit price and item code stay strict.

└─A part shipment stops reading as a mismatch
└─Billing ahead of receipt is normal; billing beyond it always escalates
└─Credit and debit notes net the invoice before it is compared

Open four exceptions instead of four hundred invoices

A weighted score costs a financial mismatch more than a logistical one, escalation fires on a variance percentage or an absolute amount in the document's own currency, and seven exception filters narrow the queue to what is worth opening.

└─Overdue, billed-ahead, over-fulfilled and unconfirmed-contract each have a filter
└─A filtered view lives in the URL, so it can be sent to whoever owns it
└─Any line can be accepted, flagged or disputed, with a name against it

How the check works

The documents, and what is compared between them.

What changes

The difference is where the check happens.

Typical practice

An invoice arrives, someone eyeballs it against a printed purchase order, and pays it if the totals look close enough. Line-level price drift is invisible.

With DocInflow

Every line is compared against order, receipt and the contracted rate with the tolerance you chose — and only the exceptions reach a person.

Typical practice

A large commitment is approved by whoever is available, in an email thread that is not part of any record.

With DocInflow

Value decides the chain, each reviewer's decision and reason sits on the document, and a send-back is a real state the requester must answer.

Not built yet — said plainly

A formal requisition stage before a purchase order exists
Per-line accepted and rejected quantity on a goods receipt
Payment execution — today the platform prepares and records, your bank moves the money

We publish what is not built yet because you will find it in the first ten minutes of a trial anyway — and because a vendor who tells you the boundary is the one worth believing about everything inside it.

The rest of the platform

It is one system underneath.

Same document layer, same control model, same audit trail — which is why a price agreed in a contract can be checked on an invoice and land in the ledger without leaving the product.

CLM

Contracts

The rate card becomes a control, not a filed document.

Explore

O2C

Order-to-Cash

Prove you delivered exactly what was ordered.

Explore

EXIM

Trade Finance

Letters of credit examined before a bank sees them.

Explore

R2R

Accounting

A real double-entry ledger, not a reporting layer.

Explore

Run it on your own documents.

A pilot runs on your paperwork, not a sample file. Send a real set — a purchase order with its invoice, or a letter of credit with its proforma invoice — and we will run the checks on it.

Request a pilot