Why hasn't my invoice appeared?

This is the most common support question we get, and in almost every case the invoice is somewhere findable rather than gone. Work through the checks in order. They are arranged by how often each turns out to be the answer, not by how interesting it is.

Before anything else: most documents appear in the inbox within seconds of the email arriving, but a large scanned PDF takes longer to read than a one-page text invoice. If the message arrived a minute ago, refresh before you investigate.

1. Was it sent to a real intake address?

Open your mailbox list in settings and compare the address, character by character, against what the sender used.

Two failures account for nearly all of these:

• The address was mistyped. Mail to an address that does not exist on your subdomain is rejected at the door, so there is no record of it in InletAP to find. The sender will have a bounce message. Ask for it.
• The invoice went to your own company address. InletAP receives mail on addresses it controls — an address on your organization's subdomain of inlet-ap.com. It cannot receive mail addressed to a domain you own, and neither can anybody else's product, because routing for your domain is decided by your DNS and your mail provider. That case is check 2.

invoices@yourcompany.inlet-ap.com   an intake address; mail arrives here
ap@yourcompany.com                  your own domain; only arrives if you forward it

Each mailbox shows when it last received a message and its volume over the last thirty days. A mailbox reading zero, on a day when you know invoices were sent to it, is a strong signal that the mail never arrived rather than that it arrived and got lost.

2. Is forwarding actually configured?

If vendors still write to ap@yourcompany.com, that mail reaches InletAP only if your provider auto-forwards it to an intake address.

Check, at your own mail provider:

• The forwarding rule exists and is enabled.
• It applies to the messages in question, and not only to mail matching a filter that this invoice missed.
• It forwards, rather than redirecting to a group that drops attachments.
• It has not been suspended by your provider, which some do after a bounce.

Send yourself a test invoice through the same path the vendor uses. If your test arrives and the vendor's did not, the difference is in the vendor's message, not your configuration. See email forwarding for the setup in full.

3. Was it caught as a duplicate?

Duplicate detection runs at ingest, on message ID, attachment fingerprint, and a vendor / invoice-number / date / amount heuristic. If the same invoice arrived twice — the vendor sent it and your colleague forwarded it as well — the second copy is marked duplicate and points at the first.

In the inbox it appears as a row with the duplicate status rather than as a missing document. Open it and you can see which document it was matched against. This is the intended behavior and not a fault, though it does mean the invoice you are looking for may be filed under a date you did not expect.

Ingest is the first check, not the only one. Later comparisons against every invoice you already hold from that vendor are described in duplicate detection, including the guards that stop an ordinary monthly bill or a vendor statement being reported as a copy.

4. Was it filtered as not an invoice?

Everything ingested is judged before extraction. Newsletters, auto-replies, bounces, calendar invites and covering notes with nothing to read are given the filtered status.

Filtered documents have their own tab in the inbox, with a count. They are not in the main list, which is deliberate: rendering a marketing email as an invoice with no vendor and a zero total helps nobody. Open the tab, find the document, and it will show the reason it was judged not to be an invoice.

If the judgment was wrong, one action puts it back into the queue and it is read normally. Filtering happens before extraction, so a filtered document has never counted against your plan, and restoring one is not a way of paying twice.

This is also where an invoice ends up when a vendor sends a bare "please find attached" with the invoice as an image the pipeline could not convert. Check the filtered tab before you conclude anything is broken.

5. Is it held on quota?

On the free plan the allowance is a hard cap: 25 processed documents a month. Beyond that, documents are received and parsed but not extracted, and they sit in held_quota.

You will see a banner at the top of the inbox counting the held documents. They are held, not lost — the parsed source text is already stored, and they are released when you upgrade or when the billing period rolls over. See plans and limits for exactly how release works.

Paid plans do not hold anything. If you are on a paid plan, this check is not your answer.

6. Is it quarantined?

A rule can quarantine a document as a policy hold — an unrecognized sender, an attachment type you do not accept. A quarantined document stops before coding and waits for a person.

If your workspace has quarantine rules, look there. If it does not, this check takes two seconds and you can move on. Rules are listed in priority order on the rules screen, so you can see which conditions could have caught the document. See the rules reference.

What each state looks like

The last row is the one that catches people. InletAP can only tell you about mail it received. If none of the five states above matches, the question moves to your mail provider rather than to this product, and the sender's own delivery record is the fastest place to settle it.

One more thing

If your team suddenly sends an implausible volume of mail into one workspace in an hour — a mailbox loop is the usual cause — the excess is stored rather than parsed, as a safety valve. The ceiling is set far above any real AP volume, so this is rare, and the messages are retained and can be re-queued. If you think this has happened, it is worth an email rather than an afternoon.

Still stuck

Write to support@inlet-ap.com with the sender's address, the intake address it was sent to, and the approximate time. Those three details are usually enough to trace a message end to end.