Coding invoices
Coding is the act of saying what an invoice is for, in the terms your books use. Extraction reads what the vendor wrote; coding decides where it lands. The two are separate on purpose, because the vendor has no idea how your chart of accounts is arranged and no reason to.
What a coded document carries
| Value | Where it lives | Where it usually comes from |
|---|---|---|
| Property | On the document, or per allocation | The property hint on the invoice, matched against your aliases; failing that, the mailbox it arrived at |
| Vendor | On the document | Matched from the extracted vendor name, or from the sender domain |
| GL code | An extracted field on the document | Read off the invoice, set by a rule, or defaulted from the vendor or property |
| Tax code | An extracted field | Read off the invoice, or your workspace default |
| Line items | Rows beneath the document | Read off the invoice, each with its own optional GL code |
| Entity and cost center | On the property record | Inherited from whichever property the document is coded to |
The distinction in that last row matters more than it looks. Entity and cost center are attributes of a building, not of an invoice, so they follow from the property rather than being set per document. Change a building's entity and every future invoice for it follows.
Defaults are marked as assumptions
When a GL code is defaulted from a vendor or a property rather than read off the page, it is stamped with a confidence of 0.5.
That number is deliberate. Extraction writes 0.8 to 0.99 when it has actually seen a code printed on the invoice, and the review threshold sits at 0.7. A defaulted code therefore reads as "assumed, please confirm" rather than "seen on the page", and it does not sail through on a confidence it has not earned. It is equally deliberately not near zero: you configured that default, so it is a standing instruction rather than a guess, and a 0.1 would render in review as though the pipeline were broken.
Splitting an invoice
Coding is no longer one property per invoice.
Line items can carry their own GL codes. A roofer's invoice with materials on one line and labor on another can be coded to two different accounts, and exports as two lines against one bill.
A line can also be split across properties. One landscaping invoice covering five buildings is coded as five allocations — evenly, by unit count, by square footage, by percent or by typed amounts — and each building carries its own share to the cent. A split invoice still shows one primary property in the inbox, the one holding the largest allocation, so a list of invoices stays readable. The full picture lives on the document. See splitting an invoice.
Two honest limits are worth knowing before you plan around this. Splitting reaches your ledger through the class on each bill line, so a QuickBooks company that does not track classes per line has nowhere to put the second property; and properties modeled as QuickBooks Locations cannot be split at all, because a location is a header field on a bill. Multi-entity QuickBooks covers both, and what happens when the buildings belong to entities with separate books.
Getting properties to resolve
Almost all coding friction is really property-matching friction, and it is fixed in one place: aliases.
A property alias is any name a vendor might plausibly use for a building. Give each property several — the marketing name, the street address, the abbreviation your maintenance team writes on job sheets, the misspelling that one contractor has used for six years and will not be talked out of:
Lakeshore Court
Lakeshore Ct
123 Lake Shore Drive
LSC
Ten minutes spent on aliases does more for coding accuracy than any number of rules, because it improves every invoice rather than the ones a rule happens to match.
When to correct by hand and when to write a rule
Correct by hand when it is a one-off: an unusual invoice, a vendor you use twice a year, a genuine mistake in extraction.
Write a rule when you notice yourself making the same correction a third time. Three is a reasonable threshold — twice is a coincidence, three times is a pattern, and a rule written after one instance is usually wrong about what the pattern actually was.
Add a vendor alias when the problem is recognition rather than coding. Aliases are created explicitly; correcting a document does not silently teach the mapping, which is a deliberate choice. Inferring standing configuration from a single hurried correction is how systems acquire behavior nobody remembers asking for.
Every change is recorded
Field edits are written to the audit trail with the actor, the timestamp, the source and the before and after values. That includes your corrections, which sounds like surveillance and is really the opposite: it is what lets you demonstrate, at year end, that a coding decision was made by a named person on a particular day for a stated reason.
Where to go next
- Splitting an invoice — one invoice, several buildings.
- Your first coding rule — stop making the same decision twice.
- Extraction confidence — why a field went to review.
- Connecting QuickBooks — how coding becomes a posted bill.
- Audit trail — what is recorded, and how to read it back.