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, duplicates and non-invoices are removed, the rest is extracted with a confidence score on every field, rules code it, a person handles whatever is uncertain, an approver decides, and the result reaches your ledger.

The pipeline at a glance

Intake

Your organization 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.

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.

Duplicate check

Detection runs at ingest, before anything reaches a queue, on three signals: the message ID, a fingerprint of the attachment, and a vendor / invoice-number / date / amount heuristic. They cover different failures: the same mail delivered twice, the same PDF forwarded from another account, and the vendor who re-sends a chased invoice as new. A duplicate is marked duplicate and stays visible rather than being deleted.

A second, wider comparison runs later, against every invoice you already hold from that vendor, and again immediately before export — see duplicate detection and Second Look.

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.

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 rather than per document. "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.

Rules and coding

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

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

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.

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. Line items that refuse to add up to the stated total escalate whatever the model claims about its own confidence: 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 field, the values before and after, and whether the source was a user, the model or a rule. 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 is a direct connector: the bill is created against the vendor and account you coded, and the identifier it returns is stored on the document, so "where did this end up" has an answer.

Everyone else gets a mapped CSV, which Xero, AppFolio, Buildium, Yardi and Rent Manager import. 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

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.