Quickstart
The aim of this page is to get one genuine invoice all the way through InletAP — from an email to a coded, approved bill sitting in your ledger. It takes about fifteen minutes, most of which is waiting for your accounting system to think about it.
Use a real invoice. Test data is reassuring and proves nothing; the whole point is to find out how InletAP handles the particular mess your vendors send you.
Before you start
You will need three things:
- An invoice that has arrived by email. A PDF attachment is typical, but a photograph of a paper bill or an invoice typed into the body of the message will do.
- Access to QuickBooks Online, if you want the last step to post automatically. If you are not on QuickBooks, you can still finish this guide — the export becomes a CSV file instead.
- About fifteen minutes. There is no implementation project, no professional services engagement and nobody from our side who needs to be on a call.
1. Create your workspace
Sign up, name your organization, and you are done. The workspace exists immediately and your first intake mailbox is issued in the same session.
Your organization gets its own subdomain of inlet-ap.com, and mailboxes live on it — something along the lines of:
invoices@yourcompany.inlet-ap.com
That address is real from the moment it appears. You can send it an invoice before you have configured anything at all, which is precisely what we are about to do.
2. Send it an invoice
Forward the invoice to your intake address.
Forward it, do not retype it. InletAP reads the MIME structure of the message, pulls the attachments out server-side, and reads the body text as well — so a vendor who cannot be persuaded to attach a PDF is still handled.
Then watch the inbox in the app. The document appears within seconds and moves through its states as the pipeline works:
| Status | What it means |
|---|---|
new | Received. The raw message is stored. |
parsed | Attachments and body text extracted from the MIME. |
extracted | Fields read from the document, each with a confidence score. |
needs_review | Something wants a human. See the next step. |
ready_for_approval | Confident enough, and coded. Waiting for a decision. |
Duplicate detection runs before any of this, on message ID, attachment fingerprint, and a vendor / invoice-number / date / amount heuristic. If you forward the same invoice twice out of nervousness — and people do — it is caught once.
3. Review what it read
Open the document. You will see the extracted fields next to the original, with a confidence score on each field rather than one score for the whole document.
This is deliberate. "This invoice is 82% correct" is not an actionable statement. "The total is certain and the invoice number is a guess" tells you exactly where to look, which is the only useful form the information can take.
Anything scoring below the review threshold routes to a human. So does an unmapped vendor, a quarantined file, and a set of line items that refuses to add up to the stated total — regardless of how confident the model claims to be. A model that is confidently wrong about arithmetic is worse than one that admits it is stuck.
Correct anything that needs correcting. Every edit is recorded with your name against it, which sounds ominous but is only how the audit trail works.
4. Code it to a property
Set the property, the GL account, and whatever else your books require — unit, entity, class, cost center.
These are fields on the document, not attributes welded to the vendor, so an invoice covering three buildings can be split across three buildings — evenly, by unit count, by square footage, by percent or by typed amounts. See splitting an invoice. The plumber who works on your entire portfolio does not have to be three separate vendors to make the coding work.
You are doing this by hand exactly once. In the next guide you turn this decision into a rule and never make it again.
5. Approve it
Approve the invoice, or route it to whoever is allowed to.
Approval tiers are banded by amount. A tier has a floor, an SLA in hours, and a number of approvers required, so "anything over five thousand needs two people and a decision within a day" is a thing you can express directly rather than approximate with a shared mailbox and hope.
6. Export it
Connect QuickBooks Online in settings and export. The bill is created against the vendor and account you coded, and the document records the external ID it came back with, so you can always answer the question "where did this end up".
Not on QuickBooks? Export produces a mapped CSV instead. Xero, AppFolio, Buildium, Yardi and Rent Manager all import it happily. It is less magical than a direct connector and it works everywhere, which on balance is a fair trade.
What just happened
You ran the whole pipeline: intake, parse, extract, review, code, approve, export. Every stage recorded who did what, when, and whether it was a person, a rule or the system.
Nothing you did was configuration. That is the intended shape of the product — you start by processing invoices, and the setup accumulates behind you as a by-product of decisions you were making anyway.
Where to go next
- Forwarding your existing mailbox — so vendors who have never heard of you keep working.
- Your first coding rule — stop making the same coding decision twice.
- Approval tiers — encode who is allowed to approve what.
- Why hasn't my invoice appeared? — for when step 2 disappoints you.