How inletAP works

This page describes the pipeline stage by stage, and says which stages are automatic and which are not. Read it if you are evaluating inletAP, explaining it to a controller, or wondering why an invoice ended up where it did.

The short version: mail arrives, the message is parsed, non-invoices are filtered out, the rest is extracted with a confidence score on every field, the property is matched and rules set the GL account, duplicates and price changes are compared afterwards, a person handles whatever is uncertain, an approver decides, and the result reaches your ledger.

The pipeline at a glance

Stage	What happens	Who does it
Intake	A message is accepted over SMTP, or a file you upload becomes one. It is stored whole.	System
Parse	Attachments and body text come out of the MIME structure.	System
Filter	Anything judged not an invoice is diverted before extraction.	System
Extract	Fields are read, each with its own confidence.	System
Rules and coding	Vendor and property resolve, then rules run in priority order.	System
Second Look	The coded invoice is compared with your history: duplicates, price moves, thresholds.	System
Review	Anything uncertain waits for a person.	You
Approval	The tier decides who signs, and how many.	You
Export	The approved bill reaches QuickBooks Online, Xero or a CSV.	You start it

Intake

Your workspace gets its own subdomain of inlet-ap.com, and intake mailboxes live on it. The address the sending server delivered to decides which workspace and which mailbox the message belongs to.

That is also why inletAP cannot receive mail addressed to a domain you own: your DNS and mail provider decide that, so an address you publish has to be auto-forwarded in. See intake addresses and email forwarding.

An invoice you upload by hand enters here too. The file becomes the message an emailed invoice would have produced — one message, one attachment, the person who uploaded it as the sender — and everything after this stage is identical. Nothing downstream can tell the two apart.

Parse

inletAP reads the MIME structure server-side: it takes the attachments out, converts HTML bodies to one stored text format, and treats the body itself as a possible invoice. A vendor who types the bill into the email and attaches nothing is still processed.

An email carrying several attachments becomes several documents, each keeping its position in the message. A processed invoice is one document extracted, so an email with three invoices in it counts as three.

Filter

A mailbox vendors know about also receives newsletters, out-of-office replies, bounces and calendar invitations. Those are judged not to be invoices and are diverted to a filtered state.

This happens before extraction, deliberately, because extraction is the step that costs an AI call and consumes your allowance. A newsletter that never reaches extraction never appears on your bill.

The gate fails in the cheaper direction. Any rule that might be wrong defers to a check for real billing evidence — an invoice word and a monetary amount together — so an invoice sent through a vendor's marketing platform survives it. Nothing is deleted: the document is retained, listed in its own view, and restoring it puts it back in the pipeline. A wrong filter costs one click, not a support ticket.

Two kinds of message are filtered without consulting that evidence, because neither can be an invoice however it is worded: a delivery status notification, and a calendar invitation. Your mail provider's forwarding confirmation is filtered as well, and email forwarding explains where to find it, because it is the one set-aside message that has to be answered.

Extract

Before an AI call is spent, the document is counted against your plan. On a paid plan, invoices above the allowance are billed at the overage rate and processing continues. On the free plan the cap is hard: the document waits in held_quota, nothing is charged, and since the parsed text is already stored, releasing it later only re-runs extraction.

Extraction then reads the fields an invoice is made of — vendor, invoice number, invoice and due dates, total, tax, currency, PO number, payment terms, remit-to details, a property hint and the line items — and scores each.

Confidence is recorded per field, and a document score is derived from it — the lowest of the four required fields, capped by the model's own overall figure. "This invoice is 82% correct" is not something anyone can act on. "The total is certain and the invoice number is a guess" tells a reviewer where to look. The review threshold is fixed at 0.7 rather than being a dial in your settings, because a threshold every workspace tunes is one nobody can reason about.

Accuracy is good on the layouts you see most and weaker on the long tail. That is the honest position, and it is why the review stage exists.

A document open beside the original PDF: the invoice number, due date, PO number, total and tax each carry their own confidence percentage, and the coding fields below them carry much lower ones. — A score per field rather than a score per invoice. The two weak numbers here are on the coding, which is what the reviewer is being asked to look at.

Rules and coding

Coding runs in a fixed order, and the order is the interesting part.

The vendor is matched on the extracted vendor name, then on the sender's domain, which often matches a vendor alias exactly.
The property is resolved from what the invoice says about itself.
If the invoice named nothing your aliases recognize, the property attached to the mailbox it arrived at is used as a fallback.
Your rules run in priority order.
Default coding from the vendor and property is applied last, so extraction and an explicit rule always win.

All of that matches against records you hold: your buildings, your units, your suppliers and their aliases. You can type them in as invoices arrive, or load them at the start from a spreadsheet you export from your own system — see importing your data.

The mailbox fallback is a fallback and not an override. A vendor who sends a Maple Street invoice to the Lakeshore address has made an addressing mistake, not a coding decision. See per-property mailboxes.

An invoice that covers several buildings is coded to several of them: a printed line can be split across properties evenly, by unit count, by square footage, by percent or by typed amounts, and the split must balance to the cent before it saves. See splitting an invoice.

Rules match on the sending address, the vendor, the amount, a keyword in the subject line, a property alias and the intake mailbox. Actions include coding, auto-approval and quarantine; the full vocabulary is in the rules reference. The rules engine and its approval tiers begin at the Starter plan.

Second Look

Once an invoice is coded it is compared with the ones you already hold, in Second Look: the attachment fingerprint, and a vendor / invoice-number / date / amount rule set, scored against your history. Invoice-number rules look back two years, and one invoice is compared against at most 200 candidates matched on the vendor or on the attachment's own fingerprint. The result is a card on the newer document naming the one it matched.

Nothing is deleted, nothing is hidden, and nothing is marked duplicate without a person pressing the button. The one thing a finding can do on its own is hold a bill back: an invoice carrying an open finding at the top severity does not leave in an export batch until somebody answers it. See duplicate detection.

The same email delivered twice never gets this far. It is collapsed at the door on an idempotency key — the workspace, the Message-ID and a hash of the raw message — so a retrying mail server does not create two documents.

Review

A document goes to needs_review when the extraction is not confident enough, when the file could not be read, or when a rule sent it there. Lines that do not add up to the stated total do not change the routing, but the document screen shows the line total, the header total and the variance, and the bill is parked at export rather than posted — a system that is confidently wrong about arithmetic is worse than one that admits it is stuck.

This is where a person belongs. The alternatives are to post a guess and fix it in the ledger later, or to have somebody check everything — one produces journal entries nobody trusts, the other is the job you are trying to stop doing.

Every correction is recorded with your name, the time, the fields you changed and their new values, and the field's source becomes user. See the audit trail.

Approval

Approval tiers are banded by amount. A tier has a floor, an SLA in hours and the number of approvers it requires, so "above five thousand needs two people and a decision inside a day" is expressible rather than approximated.

The quorum is enforced where the decision is recorded. An approval addressed to you is yours to decide; an unaddressed one can be claimed by a Controller Approver or an Admin. One person cannot sign twice to satisfy a two-approver tier. See approval tiers.

Export

Approved invoices are exported in batches, which move through pending, processing, then succeeded or failed. QuickBooks Online and Xero each have a direct connector: the bill is created against the vendor and account you coded, and the identifier the ledger returns is stored on the document, so "where did this end up" has an answer. Both connectors are included on every plan, the free one included. See connecting QuickBooks and connecting Xero.

Every other ledger gets a CSV with columns you define — seven defaults, up to 64 columns, at document or allocation granularity. There is no connector and no ready-made column set for AppFolio, Buildium, Yardi or Rent Manager. It is less magical than a direct connector and it works everywhere, which on balance is a fair trade.

inletAP does not move money. There are no payment rails, and payment happens where it happens today.

Where the humans are, and why

Decision	Made by	Reason
Is this an invoice?	System	Cheap to reverse, and wrong answers sit in one list.
What does it say?	System	Reading is what the machine is for.
Is the reading trustworthy?	System, by score	A fixed threshold is auditable.
Is the reading correct?	You, when the score is low	Corrections become rules, not busywork.
Should this be approved?	You, always	Nothing here releases a bill you did not authorize.

Where to go next

Quickstart — run one real invoice through all of it.
Invoice statuses — every state a document can hold.
Extraction confidence — how the scores are produced and read.
Your first coding rule — turn one coding decision into a standing one.