Matching the invoice to the order and the goods received

Two numbers, one supplier

The purchase order to the supplier said one amount. The invoice from that same supplier asked for another. Without a system, nobody puts the two side by side, and what the invoice says is what gets paid.

This is not a rare fault. It is the default of work split between a spreadsheet, a WhatsApp group and an email folder.

What the system compares

• What was ordered: the purchase order and the price list it was built from
• What was received: the goods receipt, marked off from a phone at the receiving door
• What is being claimed: the invoice that arrived from the supplier

Whatever does not match between the three stops and waits for a decision. The owner sees it as something requiring attention, not as a line in a report somebody may read.

Why it stops before payment and not after

Payment always goes through an approved request. There is no emergency route around the approval, and no permission that allows an unchecked invoice to be paid. A mismatch discovered after the transfer is no longer a decision, it is a correspondence.

Goods receipt from a phone

The goods receipt flow was designed for mobile first, because that is where it happens. What is missing gets marked at the receiving door rather than a week later, and without that marking the comparison runs on a figure nobody checked.

This is the point at which it is easy to give up. You can assume that what was ordered is what arrived, and then compare two documents instead of three. That assumption is almost always right, and the loss sits precisely in the cases where it is not.

Who decides on a mismatch

Not every mismatch is an error. Sometimes the price rose by agreement, sometimes a different quantity arrived by arrangement, and sometimes the supplier is right. The system does not decide for anyone; it puts the gap in front of whoever is authorised to decide, and keeps the decision.

What it does prevent is a route around it. Payment always goes through an approved request, and no permission allows the approval to be skipped. The separation between whoever approves and whoever transfers holds even when it is urgent.

Why three documents and not two

Two of the three comparisons catch most cases. Three also catch the one that costs the most money: paying in full for a partial delivery.

The four alerts this screen raises

Not every gap looks like a gap. Some of them look like a perfectly ordinary invoice, and they are caught only because something is being compared against something else.

The first three are about money that is about to leave. The fourth is about order: an unapproved order is not necessarily a mistake, but it is a state that should close before the invoice for it arrives.

What is kept from the decision

When someone settles a mismatch, the ruling itself is a record. Who approved it, when, and what the reason was. That is kept with the document rather than in the memory of whoever was there.

The practical value shows up months later, when the question is why this supplier was paid a different price from the one on their list. The answer sits on the invoice, not in the mailbox of someone who has left.

Every sensitive financial action is recorded on every plan, the free one included. A record is not a capability you buy in an upgrade.

And if nobody marked the goods receipt

Then the comparison knows less, and the system says so rather than pretending otherwise. A measure with no data behind it shows a dash and not a zero, because a zero is a claim about reality and a missing mark is an absence of information.

This is the one point in the chain that depends on a person. Everything else happens by itself: the invoice is linked, the comparison runs, the mismatch stops. The mark at the receiving door is what turns a two-document comparison into a three-document one, and that is the difference that catches the most expensive case.