Coding, close, and accuracy
Three-way match, explained for property management AP
Purchase order, goods receipt, invoice. Most multifamily portfolios run a two-way match and call it three, which is why price variances surface after payment.
Three-way match means the purchase order, the goods receipt, and the invoice all agree before anything gets paid.
Most multifamily portfolios run a two-way match, comparing the PO to the invoice, and describe it as three-way. The missing leg is the receipt, and it is the one that catches the expensive errors.
The three documents answer three different questions
Worth stating separately, because collapsing them is how the confusion starts.
The purchase order says what you agreed to buy, at what price. It is a commitment made before the work.
The goods receipt says what actually arrived or was completed. It is a fact recorded during the work.
The invoice says what the vendor is billing. It is a claim made after the work.
A two-way match compares a commitment to a claim. It never checks whether the thing happened. That works fine until a vendor bills for materials that were short-shipped, or for a service visit that was rescheduled and never occurred.
- Purchase orderWhat you agreed to buy, at what price. A commitment, made before the work.amount and account approved
- Goods receipt · usually missingWhat actually arrived or was completed. A fact, recorded during the work, by whoever was standing there.
- InvoiceWhat the vendor is billing. A claim, made after the work.agrees with the PO and the receipt before anything is paid
The receipt is skipped because in multifamily nobody is at a dock
This is the honest reason, and it is worth naming rather than treating the gap as carelessness.
A warehouse has a receiving function. A 340-unit apartment community does not. The person who would confirm that six HVAC compressors arrived is a maintenance tech who is in a unit with a wrench, and asking them to log a receipt in a procurement system competes with the actual work.
So the receipt either does not get recorded, or it gets recorded in bulk at the end of the week from memory, which is worse than not recording it because it looks like data.
That is a real constraint. Any three-way match program that ignores it will be abandoned in a month.
Where a three-way match is worth the friction, and where it is not
Not every invoice needs it. Applying it everywhere is how the process gets dropped.
| Spend type | Match worth running |
|---|---|
| Materials against a PO, over a threshold | Three-way. This is where short shipments happen. |
| Capital projects with progress billing | Three-way. Percentage complete is the whole dispute. |
| Recurring contract services | Two-way. There is nothing to receive. |
| Utilities | None. Match against the meter, not a PO. |
| Small-dollar R&M, no PO | None. The PO does not exist to match against. |
BillRoute gates three-way matching behind a per-PMC flag for exactly this reason. Turning it on portfolio-wide, for every invoice, produces an exception queue nobody works.
Match review has to allow a reasoned rejection
A match either passes or it does not, and when it does not somebody has to decide why.
The useful design is accept or reject with a reason, recorded. Not because anybody enjoys the extra click, but because the reason is the data. Ten rejections tagged "PO never updated after scope change" tells you the PO process is broken. Ten tagged "vendor billed wrong unit" tells you a vendor needs a conversation.
Without the reason you have a count of exceptions and no idea which of your four possible owners should fix anything.
BillRoute records match review as accept or reject with a stated reason, and surfaces matched invoices from the PO so you can jump between them rather than searching.
Encumbrance is the part that makes budgets real
A purchase order that does not move a budget number is a document, not a control.
The sequence that works: a PO is approved, that amount is encumbered against the property's budget, and available budget drops immediately. When the invoice posts, the encumbrance releases and actual expense records.
Without encumbrance, a property manager can approve four POs against a budget line that only supports two, and nobody knows until the invoices arrive in the same month.
BillRoute tracks budgeted, encumbered, actual, and available per property and account, updating as POs move through their lifecycle. Worth noting it is behind its own flag, because a portfolio without a PO discipline will not benefit from encumbrance tracking on top of it.
Start with one spend category
Do not turn on three-way matching portfolio-wide.
Pick the category where short shipments and partial completion actually cost you, which in most portfolios is materials over a dollar threshold or capital progress billing. Require receipts there only. Measure the exception rate for a month, and read the rejection reasons.
If the reasons cluster on "PO never updated," your problem is upstream of matching and matching will just surface it repeatedly.
Which category would you start with?
Keep reading
Coding, close, and accuracy
GL coding for property management: building a chart of accounts that codes itself
Coding automation learns from your history, so an inconsistent chart of accounts produces a faster inconsistent chart. Fix the GL first, then automate it.
Coding, close, and accuracy
The multifamily month-end close checklist, AP section
Close is late for two reasons: AP is still coding, and nobody can see what has not posted. Six things have to be true on the last day, and each is a query rather than a conversation.
Coding, close, and accuracy
The invoice that arrives on the 8th for work done on the 28th is the accrual problem
Period expense is set by when the service happened, not when the invoice showed up. Slow AP makes that gap large enough to distort a property's month.