inletAP
Start free
Invoice coding

What invoice coding is, and why it is the slow part

Invoice coding is the step where you record what a bill is for, in the terms your own books use: which general ledger account it belongs to, which property it relates to, and which tax treatment applies. None of that is printed on the invoice, because the vendor has no idea how your chart of accounts is arranged. This page defines the job, then shows what a system can honestly take off your hands.
Start freeRead the coding reference

The free plan processes 25 invoices a month with unlimited users, takes no credit card and does not expire. You get your own intake address at the end of setup.

The definition, and the distinction that matters

Coding is the translation step between a document somebody else wrote and a ledger you have to defend. Extraction reads what the vendor wrote. Coding decides where it lands.

The two are separate on purpose. A plumber sends the same invoice whether you book it to Repairs and Maintenance or to Capital Improvements, and whether it belongs to one building or four. The document is identical either way; the decision is entirely yours, and it depends on facts the vendor could not know — how your accounts are arranged, who owns which building, and what you did with a similar bill last spring.

This is why capture accuracy, which is what most of this category advertises, does not settle the question. A general ledger code is not printed on a vendor invoice and never has been. You can read a document perfectly and still have no idea which account it belongs to. In inletAP, extraction does not attempt to read GL codes off the page at all — a code arrives from a rule you wrote, from a default set on the vendor or the property, or from a person typing it, and the source is recorded either way.

A coded document ends up carrying more than an account. It carries the property the cost belongs to, the vendor it came from, the tax treatment, a cost center if you use them, and the owning entity — which follows from the property rather than being set per invoice, because an entity is an attribute of a building and not of a bill. Line items sit beneath it, and a line can carry its own account once it is split.

The reason coding is the stage firms automate first is that it is repetitive without being simple. Most invoices in a given month are the same vendors doing the same things at the same buildings, which is standing decisions rather than new ones. But a meaningful minority are genuinely new, and those need a person. A system earns its place by handling the first group silently and being honest about the second, rather than by guessing confidently at both.

Capabilities

What a coded invoice actually carries

The values that make up a coded document, and where each one comes from. This is the shape of the job in any AP system; the parenthetical notes are how inletAP fills each field.

The GL account

The line in your chart of accounts the cost belongs to, and the value your income statement is built from. It is never printed on the invoice. In inletAP it is written by a rule, defaulted from the vendor or the property, or typed — and each source is stamped with a different confidence, so a default never looks like a decision.

The property, and the entity behind it

Which building the cost belongs to. Resolved from the property hint on the document, matched against the aliases you keep on each property, and failing that from the intake mailbox the invoice arrived at. The owning entity is inherited from the property rather than coded per invoice, so changing a building's entity moves every future bill with it.

Vendor, tax and cost center

The vendor is matched from the extracted name or from the sender's domain, and carries its own coding aliases and default account. The tax code comes from your workspace default when the invoice states tax, or you type it. A cost center is always typed, never read off the document — a property can hold a default one for your own reference.

Line items, and when they need their own code

Lines are read off the invoice. An invoice you have not split posts every line on the document's own GL code, which is right for the large majority of bills. A roofer billing materials and labor on separate lines is the case where it is not, and that is what splitting a line is for.

Allocations across buildings

One invoice covering five properties becomes five allocations — evenly, by unit count, by square footage, by percent or by typed amounts — each carrying its share to the cent. A split invoice still shows one primary property in the inbox, the one holding the largest allocation, so a queue stays readable.

Rules, for the decisions you have already made

A rule matches on the source email, the vendor, the amount, a keyword in the email subject, a property alias or the intake mailbox, and can set the GL code, assign a reviewer, quarantine the document or mark it ready for approval. Conditions combine with AND. Rules are workspace-wide; to act on one building, match on that building.

Why this one

The limits, stated plainly

Coding automation is where this category over-promises hardest, so here is what inletAP does not do. Every line is a real boundary in the shipped product rather than a roadmap note.
  • A rule can set the GL code. It cannot set the property, the vendor, the class or the tax code. There are exactly four rule actions — set the coding, assign a reviewer, quarantine, or mark ready for approval — and no others exist.
  • Marking a document ready for approval is not approving it. A human still approves. Nothing in the rules engine can pay or post a bill by itself.
  • Rules live at the workspace level. A rule cannot be scoped to one property; if you want per-building behavior, you write a condition that matches the building, by property alias or by the mailbox it arrived at.
  • A keyword condition reads the email subject only. It does not search the text of the PDF, and a rule written expecting it to will match nothing.
  • Conditions combine with AND only. There is no OR, no nesting, no regular expressions, and no condition on a date, a currency or a line item.
  • Extraction does not read GL codes off the document. Anything that tells you it reads your chart of accounts off a vendor invoice is describing something else.
  • Splitting a property across a QuickBooks Online bill needs class tracking on the line. Properties modeled as QuickBooks Locations cannot be split, because a location is a header field on a bill rather than a line field. Neither limit applies to Xero, which carries tracking on the line.
  • No published accuracy rate for automated coding, ours or anyone's. Coding correctness depends on your chart of accounts and your own past decisions, so a vendor-published percentage would describe a test set rather than your books.

Compare

Three ways a GL code lands on an invoice

Not a competitor table. These are the three sources inletAP will accept for an account code, and they are deliberately not treated as equally trustworthy.
The confidence numbers are product behavior, not marketing: a rule-written or typed code is stamped at 1.0, a vendor or property default at 0.5, and the review threshold is 0.7. The threshold is fixed and is not a setting.
 Typed by a personWritten by a ruleDefaulted from vendor or property
Confidence recordedFull — somebody decidedFull — you decided in advance0.5, meaning assumed rather than decided
Clears the 0.7 review thresholdYesYesNo — it stops for a human, which is the point of the number
Applied whenAt review, on the invoiceAfter extraction, on every matching documentLast, after extraction and rules, so it never overwrites either
Good forThe genuinely new billThe vendor you have already made a standing decision aboutA reasonable starting guess that is visibly a guess
Recorded in the audit trailYes, with the person and the timeYes, naming the ruleYes, as a default

The confidence numbers are product behavior, not marketing: a rule-written or typed code is stamped at 1.0, a vendor or property default at 0.5, and the review threshold is 0.7. The threshold is fixed and is not a setting.

Pricing

Coding rules are on every plan, including the free one

Rules, vendor and property defaults, splitting across properties and line-level coding are not gated behind a tier. The free plan covers 25 documents every month, takes no credit card, and carries the same coding behavior as the paid ones.

Prices are in US dollars and exclude sales tax, which is added where it applies.

Paid plans renew automatically at the price shown — every month, or every 12 months on annual billing — until you cancel. Cancel any time in billing settings: the next renewal stops and you keep the period you have already paid for.

See all plans

Invoice coding — common questions

What is invoice coding?
Invoice coding is the step in accounts payable where you record what a vendor invoice is for, in the terms your own books use: which general ledger account it belongs to, which property or department it relates to, and which tax treatment applies. The vendor writes what they did and what it costs. Coding decides where that lands in your chart of accounts, so the bill can be posted, reported on and closed. It is bookkeeping judgment applied to somebody else's document.
What does it mean to code an invoice in accounts payable?
It means attaching your own accounting dimensions to a document that arrived with none of them. A plumber's invoice says what was fixed and what it cost. Coding it says that the $840 belongs to account 6120 Repairs and Maintenance, against the Harborview building, owned by the entity that holds Harborview, with no sales tax to recover. None of those four facts are on the page the plumber sent, and none of them can be read off it. They come from how your books are arranged, which is why coding is a decision rather than a transcription.
What is coding in invoice processing?
Invoice processing is the whole path from a bill arriving to it being paid and posted. Coding is one stage inside that path, and it sits after capture and before approval. Capture reads the document. Coding classifies it. Approval authorizes it. Export posts it. The stages are worth keeping separate because they fail differently: a capture error is a wrong number you can see on the page, and a coding error is a right number filed in the wrong place, which is invisible until somebody reads a report and does not recognize it.
Is invoice coding the same as OCR or data extraction?
No, and conflating them is the most common mistake in this category. Extraction reads what the vendor wrote — the vendor name, the invoice number, the date, the amount, the line items. Coding decides where those values belong in your books. A GL code is not printed on a vendor invoice and never has been, so no amount of reading accuracy produces one. In inletAP, extraction does not read GL codes off the page at all. A code arrives from a rule you wrote, from a default on the vendor or property, or from a person typing it.
Who codes invoices?
In a small firm, usually a bookkeeper or an office manager, often the same person who opens the mail. In a larger one, an AP clerk codes and a controller sets the standard and spot-checks it. The work is unpopular for a reason that is structural rather than lazy: it is repetitive enough to feel mechanical, but it carries real judgment, so it cannot simply be handed to the least experienced person in the room. That gap is why coding is the stage most firms try to automate first.
Can invoice coding be automated?
The repetitive part, yes. The judgment, no, and a product that claims otherwise is describing a demo. The reliable pattern is that standing decisions you have already made get applied without you: this vendor always goes to this account, mail to this address is always this building. What cannot be automated is the first invoice from a new vendor, a bill that covers two unrelated jobs, or anything a person has never made a decision about. A useful system codes the boring majority, marks the rest as unconfirmed, and makes it obvious which is which.
What is a GL code on an invoice?
A general ledger code, sometimes called a GL account or an expense account, is the line in your chart of accounts that the cost belongs to — Repairs and Maintenance, Landscaping, Utilities, Capital Improvements. It is the single most consequential coding decision, because it is what your income statement is built from. It is also the one most exposed to drift: the same landscaping bill booked to Grounds Maintenance in March and Repairs in April makes a year-over-year comparison meaningless, and nobody notices until the close.
How do you code one invoice across several properties?
You split it. 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 share to the cent. A line can also be split to carry its own GL code, which is how a roofer's invoice with materials on one line and labor on another posts as two accounts from one bill. An invoice you have not split posts every line on the document's own code.
What happens when the software is not sure how to code something?
In inletAP it says so, with a number rather than a shrug. A GL code written by a rule or typed by a person is stamped at full confidence. A code that came from a default on the vendor or the property is stamped at 0.5, which reads as an assumption to confirm rather than a decision somebody made. The review threshold sits at 0.7, so a defaulted code cannot sail through on confidence it has not earned — it stops for a human. That threshold is fixed at 0.7 and is not a setting.

Keep reading

Coding invoices, in the docsThe screens, the fields, where each value resolves from, and how to fix one that resolved wrong.Write your first coding ruleThe six conditions, the four actions, and the order rules run in.Splitting one invoice across propertiesAllocation by units, square footage, percent or amount — and what each ledger can accept.What the confidence numbers meanWhy a defaulted code is 0.5, and what the 0.7 review threshold does with it.

Code a month of real invoices and see what it gets right

Forward a month of bills from the vendors you know best to your intake address, write one rule for the vendor you code most often, and see how much of the queue codes itself. The free plan covers 25 documents every month and takes no credit card.

Start freeTalk to us first