Invoice coding

Coding an invoice records what it is for, in the terms your own books use: which general ledger account it hits, which building carries it, which cost center it belongs to. Extraction reads what the vendor wrote; coding decides where it lands. The two are separate because the vendor has no idea how your chart of accounts is arranged and no reason to.

This guide codes one invoice by hand. Doing it once is the job; doing it three times is a signal to write a rule instead.

Where the coding lands: a QuickBooks class, a Xero tracking option

Coding is recorded in inletAP's words — property, GL code, cost center — and each of them becomes a field on the bill when it posts.

QuickBooks Online. Each line carries the account its GL code is matched to — or your default expense account — and its property as a class where the file tracks classes. Class is a per-line field on a QuickBooks bill, which is what lets one bill carry several properties.
Xero. Each line carries the account code its GL code is matched to — or your default expense account — plus the property as a tracking option where you use tracking. The ceiling is Xero's: an organization defines at most two tracking categories in total, so your properties have to be one of the two you already use.

Neither name is typed on the invoice. Accounts, classes and tracking options are matched to your own records once, on Exports → Ledger setup, and the fields below name the inletAP record that resolves to them at export.

Before you start

An invoice to code. Open one from Inbox. Anything the pipeline wants a person to look at is also gathered in Review Queue, and both open the same document screen.
The right role. An Admin, a Controller Approver or an AP Specialist may code an invoice. A Viewer — the outside-approver role — may not edit one at all. See roles and permissions.
The building and the vendor already in inletAP. Both are pickers, and they offer only records your workspace holds, so you cannot invent a property while looking at the invoice. Add it under Properties first, or load the whole portfolio at once — see importing your data.
Two values you will not be asked for. The entity comes from the property's own record, and the class is resolved at export from your property-to-class mapping. Neither is a field on the invoice.

1. Open the invoice and read what was extracted

The original document is on the left, the fields it produced are on the right, and each field carries its own confidence score. Read the two against each other before you change anything. A low score is a pointer, not a verdict: it tells you which field to look at, and the document is still yours to correct wherever the score sits.

The document screen: the invoice PDF on the left, and on the right the Coding section with Property, GL account, Cost center and Memo, each extracted field showing its confidence. — Coding is one section of the document screen, under the header and the amounts, above the line items.

2. Settle the vendor and the total first

They sit above the coding fields on the screen, and they belong first for three reasons. The vendor supplies the default GL account when nothing else has. The total is what the invoice is matched to an approval tier by. And a split, if you make one, is balanced against the total less the tax, so correcting either figure afterwards means checking the split again.

If the line items do not add up to the stated total, the screen says so with the variance. That stops the bill at export rather than at review, so your ledger is never sent a total the lines do not support.

3. Fill in the Coding section

Four boxes, and filling them top to bottom is the right order.

Property. The building this invoice is for, picked from your properties. The building's photo, code and city appear above the picker, which is worth a glance: a portfolio with a Cedar Ridge and a Cedar Court is two letters away from an expensive mistake.
GL account. The account the bill hits. Type it, or accept what a rule or a default already put there. Extraction never reads a GL code off the page — a vendor does not know your chart of accounts, so there is nothing on the invoice to read.
Cost center. Typed on the invoice, never read from it.
Memo. A note that stays on the document. It is not sent to your ledger, and correcting a memo alone is treated as immaterial: it does not make you the preparer of the invoice.

Coding lives on the document, not on the vendor. The plumber who works on your whole portfolio does not have to be three separate vendors for the coding to work.

4. Split it, if it covers more than one building

Skip this step unless it does. One landscaping invoice covering five buildings is coded as five allocations in the Split coding grid — evenly, by unit count, by square footage, by percent or by typed amounts — and each building carries its own share to the cent. A line can also be split so that each part carries its own GL account, which is how a roofer's materials and labor reach two accounts on one bill.

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 is on the document. See splitting an invoice.

5. Save

Press Save. In a queue the button is Save & next, which saves and opens the next invoice; at the end of the queue it reads Save & finish and returns you to the list. Pressing Send to approval or Approve with unsaved edits saves them first, and the screen says so before it does, so the approver sees the coding you corrected rather than the coding the extractor produced.

What you should now be looking at: the same invoice, with your values in the Coding section and a confidence of 100% on every field you set. That is not a flourish — a value a person typed is stored at full confidence with user as its source, which is what separates a decision from an assumption further down the pipeline.

6. Prove the coding stuck

Two checks, and they answer different questions.

On the document. Reload it. The fields hold your values and read 100%. If a field has gone back to what it was, the save did not complete — the screen says so at the time, and it never reports a save it did not make.

In the trail. Open Audit Log and paste the document id into the record filter. Your edit is there as Fields Updated, with the old value struck through beside the new one; opening the entry names the actor, the field and the timestamp. That is the answer to "who coded this, and when", and it is why the recording exists — not surveillance, but the thing that lets you demonstrate at year end that a named person made a coding decision on a particular day.

What is typed here, and what is resolved elsewhere

Only some of a coded document is typed on the document.

Picked or typed on the invoice: the property, the vendor, the GL account, the cost center and the memo. The property is suggested first — from a property hint on the invoice matched against your aliases, failing that from the mailbox it arrived at — and the vendor is matched from the extracted name or the sender's domain. Both are suggestions you confirm or replace.

Inherited from the property: the entity. It is an attribute of a building, not of an invoice, so it follows from whichever property the document is coded to. Change a building's entity and every future invoice for it follows.

Resolved at export: the class. It comes from your property-to-class mapping, per line, at the moment the bill is built, which is what makes a split invoice reach several buildings on one bill.

From a default, or picked by a person: the tax code. When an invoice states tax and names no code of its own, inletAP gives it a default tax code. You can also pick the code yourself under Tax code in the Coding section of the invoice screen. The list there is your ledger's own tax codes. You set the defaults beside the other ledger defaults on the Exports screen: one default purchase tax code for the workspace, and, if you want, a code for each province or state where you have properties. inletAP picks the default like this:

The property's province or state has a code of its own: that code.
It has none, and all your properties are in one province or state: the workspace default.
It has none, and your properties are in more than one province or state: no default. A person picks the tax code on the invoice screen. An invoice with no property yet gets no default either.

A tax code a person chose never changes. A default can: if you move the invoice to a property in another province or state, the default follows the new property. A posted bill does not change. Under the code, the invoice screen says where it came from: picked by a person, the default for a province or state, or the workspace default. Without a tax code, a taxed invoice waits on the Exports screen rather than posting your vendor short. There, Pick a tax code opens the invoice at the tax code. Pick one, then retry the export. Set a default tax code beside it helps the invoices that come after; it does not change one that is already waiting.

Read off the invoice: the line items. Coding a line to its own account is done by splitting the line.

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. A rule that names a code writes it at 1.0, and so does a person who types one; the review threshold sits at 0.7. A defaulted code therefore reads as "assumed, please confirm" rather than "somebody decided this", 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.

Two limits on splitting, and both are QuickBooks Online's

A split reaches QuickBooks 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. Properties held as QuickBooks Locations cannot be split at all, because a location is a header field on a bill. Neither limit exists on Xero, which carries tracking on the line — see connecting Xero. Posting to several companies 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

Aliases live on each building's own page under Properties: open the building and add them under Coding aliases. 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.

Common questions about invoice coding

What is a GL code?

The identifier of an account in your general ledger, such as an account for repairs or for utilities. Coding an invoice to a GL code is what makes it show up in the right line of a profit and loss statement. In inletAP the GL code is a field on the document, and extraction never reads it off the page.

Can invoice coding be automated?

Partly, and it is worth being precise about which parts. A rule can set the GL account. The property is resolved from a hint on the invoice, from a property alias, or from the mailbox the invoice arrived at. The tax code comes from your defaults when the invoice states tax: the code for the property's province or state, or the workspace default when all your properties are in one province or state. Line items are read off the invoice. Anything a rule did not set is still yours to confirm, and a value defaulted from a vendor or property is stamped at 0.5 confidence so it reads as an assumption rather than a decision.

What happens if an invoice is coded wrongly?

You correct it on the document, opened from the Inbox, and the correction is recorded with who made it and when. Whether to fix one invoice by hand or write a rule instead is answered in when to correct by hand and when to write a rule above.

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 Online and connecting Xero — how coding becomes a posted bill.
Audit trail — what is recorded, and how to read it back.