Approving a Supplier Invoice Before Payment: Separating Intake, Approval and the Masav File

The payment file is the last output in the chain, not the process. Before it sit three separate stages that must be in different hands: taking the invoice in, matching it to a purchase order and a delivery note, and approving the payment itself. When one person does all three there is no control point - only a record.

The three acts that must sit in different hands

Segregation of duties in supplier payments is exactly three questions somebody else answers:

In a three-person business you cannot split this into four roles, so the practical rule is narrower: whoever maintains supplier bank details is not whoever approves the payment. That is the one separation you never give up, because it is the only one that prevents a payment destination changing without a witness.

What does the three-way match actually check?

The three-way match compares three numbers that should be identical and frequently are not. A worked case: purchase order PO-2026-0342 for 500 units at 12.40 each, 6,200 in total.

• Delivery note DN-88214: 480 units received. Twenty short.
• Supplier invoice 2026/4471: 500 units, 6,200.
• The gap: 248 paid for goods that never arrived, if the invoice is paid as presented.

Four exception types come out of that comparison, each with a different owner:

1. Quantity exception - less delivered than ordered. Owner: whoever booked the goods in.
2. Price exception - invoice price differs from the order price. Owner: purchasing.
3. Invoice with no order - no purchase order exists at all. Owner: the manager who actually ordered it.
4. Receipt with no invoice - goods arrived and no invoice followed. Owner: bookkeeping, and it is an open commitment that belongs in the reports.

The exception threshold has to be defined numerically rather than by feel: for example a price gap up to 1% or up to 50 passes automatically, and anything above stops. A written threshold turns most invoices into a quiet flow and leaves a person only what genuinely deviates.

The state machine for a supplier invoice

• received - taken in, document present, supplier identified. Moves to matching or rejected.
• matching - being compared to order and delivery note. Moves to matched or exception.
• exception - a gap was found. Moves to matched after a recorded decision, or to rejected.
• matched - reconciled. Moves to approved.
• approved - approved for payment, with an approver and a timestamp. Moves to scheduled.
• scheduled - included in a payment proposal with a value date. Moves to paid.
• paid - settled. Terminal.

One rule holds the whole thing together: nothing reaches scheduled without passing through approved, and approval is granted for a specific invoice at a specific amount. A blanket approval for "anything from this supplier" removes the mechanism entirely.

What the payment file actually consumes

A payment run does not read invoices. It reads a payment proposal - a separate object created at run time that snapshots what was approved. Its fields:

Before the file is produced, the proposal goes out for sign-off, and the reviewer looks at exactly three things: lines carrying flags, lines whose amount deviates from that supplier's historical average, and suppliers never paid before. After sign-off, any change to the proposal voids the approval and requires a fresh one - otherwise a line can be added after the manager looked.

From that point a different subject begins: file structure, format rules and the reasons an entire batch is rejected are covered in errors in Masav supplier payment files. This article stops exactly where the proposal is approved.

Why must a bank-detail change follow its own path?

A bank-detail change needs its own path because it is the only action in the process that redirects money without altering any amount. A forged invoice looks suspicious; a changed account number looks like a routine data update.

• The change request is never taken from the document. An invoice showing a new account is not a change request.
• Verification runs outbound, not inbound: you call the number that was on the supplier record before the request arrived.
• The change is written as an event with user, timestamp, previous value and new value.
• The first payment after a change is marked in flags and needs an additional approval.
• A notice of the change goes to the previous contact at the supplier, who is exactly the person who will object if they did not ask for it.

The other supplier checks - certificates and their validity - are covered in automated supplier verification, and the document-capture side in processing Hebrew supplier invoices.

What actually breaks at the intake stage

• Double intake - the same invoice arrives by email and is also scanned. The uniqueness key must be supplier identifier plus the supplier's own invoice number, never an internal running number.
• Non-numeric invoice numbers - suppliers use 2026/4471 or A-118. A numeric field silently drops the separator.
• Consolidated invoices - one document covering six orders. If the link is a single field, five orders stay open forever.
• Supplier credit notes - they arrive as a separate document and must be linked to the original invoice before they can be netted in a run.
• Currency - a foreign-currency invoice stored in shekels at the day's rate produces a permanent gap against what is actually paid.

Sources

• Masav - payments to suppliers
• Masav - file specifications and additional information