What a Vendor Portal Wants and Why Invoices Come Back

Why this matters

An institutional invoice is not read. It is matched. Before any human looks at it, a system compares three records - the purchase order, the receipt of goods or services, and your invoice - and if any field disagrees, the invoice is returned with a code and no explanation. Shops respond to that by getting defensive about the work, which is the wrong instinct, because the work is not what failed. The invoice failed a field comparison against a record you have never seen.

The habit that fixes this is small and it inverts how most shops invoice: build the invoice from the purchase order, not from your job record. Your job record is the truth about what you did. The purchase order is the truth about what they are permitted to pay for. When those two disagree, the purchase order wins every time, and the gap has to be closed before the invoice goes out, not after it comes back.

What the portal will never tell you

This is the useful part of the subject, because everything the portal does say is on the screen already. What it withholds is where the money sits.

It will not tell you that nobody received the work. The three-way match needs a receipt, and on a service job the receipt is a person at the institution clicking a button to confirm the service happened. Nobody clicks it automatically. An invoice waiting on a receipt is not rejected and not approved - it sits in a pending status that generates no notification, produces no rejection code you could respond to, and ages quietly past your terms. This single condition accounts for more genuinely stuck institutional invoices than every rejection code combined, and it is invisible because the system considers itself to be working correctly.

It will not tell you the purchase order is nearly exhausted. A blanket purchase order carries a not-to-exceed value for a period. Once your cumulative invoicing approaches it, the next invoice fails on remaining balance, not on anything about that invoice. The portal shows you your invoices; it usually does not show you the encumbrance left on the order unless you go looking.

It will not tell you the fiscal year closed. A purchase order funded from one fiscal year generally cannot pay for work performed in the next one. Work done in the last week of the year and invoiced three weeks later can land against an order that no longer has a live funding source, and the fix is a new order, which means a new requisition and a new approval chain.

It will not tell you which rejection code means what. The codes are internal. Ask your buyer once for the list, write it down, and stop guessing.

It will not tell you what it costs you. Many institutions transact through a third-party supplier network that charges the vendor either a percentage of invoice value or a per-document fee. That fee is a real reduction in your realized margin on that account and it belongs in your pricing, not in your surprise.

The rejection causes worth memorizing

Most codes reduce to one of these, and each has a source-side fix rather than a resubmission fix.

That last row is the one with teeth, and it is worth stating plainly: on public-entity work, an authorized purchase is generally the act that obligates public funds, and work performed before an order exists may not be enforceable against the entity at all. Charters, statutes and dollar thresholds differ by jurisdiction and entity type, and some bodies can ratify an unauthorized purchase after the fact, but ratification is discretionary and a facilities director's verbal approval is not a substitute for it. Treat "start Monday, the paperwork is coming" as unfunded work you are choosing to gamble on, and size the gamble accordingly.

Worked example: an invoice rejected three times

A shop completes an emergency repair at a county facility. Their own job record shows 12.5 labor hours, one control component, and a subcontracted crane pick. They invoice as three lines.

Rejection one, code for line mismatch. The purchase order has a single line reading "Emergency HVAC repair, Building 4, lump sum, 1 EA". The buyer created it that way because the requisition was written before anyone knew what the repair would be. Their invoice's three lines cannot map to one order line, so the match fails. The fix is not to argue that three lines are more transparent. It is to invoice one line, quantity 1, unit "EA", with the three-line detail attached as a supporting document. The detail still travels, it just stops being the thing the machine is matching on.

Rejection two, duplicate invoice number. The shop resubmitted under the same number. The system had already recorded that number against the rejected document. Resubmission number carries a suffix from then on.

Rejection three, amount exceeds order. The order was written at a not-to-exceed the requisitioner guessed at before the crane was known. The invoice sits 18 percent above it. Nothing in the invoice is wrong; the order is short. This one cannot be fixed on the vendor side at all. It takes a change order to the purchase order, which is a new requisition, a new approval, and in this shop's case 11 additional days.

Count the elapsed time. Work completed day zero, first invoice day 4, rejected day 6, resubmitted day 7, rejected day 8, resubmitted day 9, rejected day 12, purchase order increased day 23, invoice accepted day 25, and net 45 from acceptance means payment around day 70. Two of the three rejections cost about two days each; the third cost 13 days on its own. Against a straight-through path where acceptance would have landed on day 6 and payment around day 51, the total slip is 19 days, and 13 of those 19 - just over two thirds - came from the single failure the shop could have caught before starting: nobody compared the order's not-to-exceed against the emerging scope while the crane was still being scheduled.

The reasoning to carry. The two cheap rejections were formatting. The expensive one was a scope-versus-encumbrance divergence that existed on day zero and was discoverable on day zero. Rejections are not equally costly, and sorting them by cost tells you where to put the checking effort. Reformatting an invoice is a five-minute fix at any point. Raising an order is a multi-week fix that gets worse the later you find it.

The failure mode. A shop that treats all rejections as clerical builds a habit of resubmitting fast and checking nothing, which handles the two-day problems well and lets the 13-day problem run until the invoice is already stale. The tell is a receivables report where most institutional invoices clear on schedule and a small number are three times older than the rest. Those are never formatting.

What to do when the invoice is not rejected and not paid

Aging with no rejection code almost always means no receipt was entered. Do not resubmit; a duplicate will reject and you will have learned nothing. Call the person who authorized the work, not accounts payable, and ask them to receive it in the system. Accounts payable cannot receive on someone else's behalf and will tell you the invoice is in order, which is true and useless.

Get that person's name at the time the work is authorized, every time, and put it on the ticket next to the purchase order number. On a standing agreement the receiver may not be the requester, and when the receiver is on leave the queue simply stops.

How to verify you got this right

Before an invoice goes out, hold it beside a printed copy of the purchase order and check five fields against the order rather than against your job: order number, line structure, unit of measure, cumulative amount including this invoice against the not-to-exceed, and tax treatment. Then confirm the service date falls inside the order's validity window and inside the fiscal year that funded it.

If you cannot answer "what is left on this order" without calling someone, you do not have the encumbrance tracked, and that is the gap that produces the expensive rejection rather than the cheap one.

References

• Generally accepted three-way match practice in accounts payable (purchase order, receipt, invoice)
• State and local public purchasing statutes governing authorization and ratification of purchases; requirements vary by jurisdiction and entity type
• See related: How to Get Set Up as an Approved Vendor, Net Terms and What They Do to a Small Shop's Cash Position, What Makes an Invoice Easy to Approve