Seven fields on an invoice decide whether it can be coded without a phone call

Most AP exception handling is not a systems problem. It is an invoice arriving without the information needed to code it, and somebody spending eleven minutes finding out which property it belongs to.

Publishing seven required fields and enforcing them removes the majority of that work, and it is the cheapest change available in accounts payable.

The seven

Property identifier. The single most important field and the one most often missing. A vendor working eleven of your properties who writes only your company name has produced an invoice that only the person who called them can code.

Give vendors your property codes and require one on every invoice. Not the property's marketing name, which changes, and not the address, which vendors mistype. The code that exists in your system.

Unit number, where the work was in a unit. Without it you can code to the property and not to the right expense category, since a make-ready repair and a common area repair are different accounts.

Invoice number, unique per invoice. A vendor who numbers everything 1001 or leaves it blank makes duplicate detection impossible and makes your own reference to the invoice ambiguous.

Invoice date and service date, separately. These are different and both matter. The invoice date drives payment terms. The service date drives which accounting period the expense belongs to. A vendor giving you only the invoice date has made your accruals somebody's estimate.

Purchase order number, where one exists. A PO-backed invoice with no PO reference cannot be matched, so it goes to an exception queue to have the PO found by hand.

Line-item detail with quantities and unit prices. A single line reading "maintenance work, $2,340" cannot be coded at line level and cannot be price-checked against a PO. Three lines with quantities can be.

Remit-to information matching your vendor master. A remit-to address or account that differs from what you have on file is either a change you were not told about or something worse. More on that below.

The reason to require them is that coding is downstream of all of them

GL coding at the line-item level needs to know the property, the unit, and what the work was. Those three determine the account.

A vendor supplying all three lets coding happen automatically against your historical pattern for that vendor and that category. A vendor supplying none of them means every invoice is an exception, and an exception queue is where AP hours go.

Which is why the fix belongs in vendor onboarding rather than in AP. The invoice format is decided when the vendor is set up, and correcting it afterward is a per-invoice conversation forever.

One page, sent at onboarding, is the whole enforcement mechanism

The requirement only works if vendors know it, and most vendor agreements bury insurance requirements and say nothing about invoice format.

A one-page invoice submission standard, sent at onboarding and attached to the vendor agreement, covering:

The seven fields, with an example invoice showing where each goes.

Where to send it. One address, and the statement that invoices sent anywhere else will be delayed.

What happens to a non-compliant invoice, specifically that it will be returned rather than corrected on your side.

Your property code list.

That last item is the one vendors most appreciate and most rarely receive.

Enforcement has to be real or the standard decays

A standard that is published and not enforced trains vendors that it is optional, and within a quarter you are back to interpreting invoices.

Returning a non-compliant invoice feels adversarial and is the only thing that works. The alternative is your staff doing the vendor's data entry indefinitely.

Two ways to make it less adversarial. Return it with the specific missing field named, rather than a generic rejection, so the vendor can fix it in a minute. And give the vendor a way to see that their invoice was received and what state it is in, so a return does not read as silence.

Where our own automation lands, and what it does not fix

The extraction side handles more variance than a standards document assumes. Vendor-specific templates registered from a sample PDF, with layout variants, so a vendor whose invoice format is unusual and consistent gets read correctly. Handwritten field vendor invoices are read alongside digital ones. Multi-invoice PDFs are detected and split, with the page assignment reviewed by a person rather than applied automatically.

Validation surfaces the specific problem rather than a generic failure: Supplier Code Mismatch, Property Code Mismatch, Price Mismatch, Failed Extraction, Missing Invoice Number. A named error is actionable and a rejection is not.

Where extraction cannot help: a field that is not on the document. If the invoice does not name a property, no amount of reading finds one. Our own automation rate is 98%, and the residual is heavily weighted toward invoices missing information rather than invoices that were hard to read.

That is the honest case for the standard. Automation handles format variance. It cannot handle absence.

What we do not do

We do not onboard your vendors or enforce your standard for you. Returning a non-compliant invoice is a decision your team makes.

We do not verify a banking change. The callback control above is a human process and any system that auto-accepts a remit-to change from a document is a liability.

Count your exceptions by cause

Take last month's exception queue. Categorize each item by which of the seven fields was missing or wrong.

Whichever field tops that list is the one line to add to your vendor onboarding document this week.

Which was it?