--- title: What you can send description: The twenty file types inletAP accepts, the 20 MB ceiling, what happens to a file it cannot read, and when to upload, email or forward. section: Getting started order: 7 --- # What you can send Short answer: a PDF, a photograph, a Word file, a spreadsheet or plain text, up to 20 MB, by upload or by email. The rest of this page is the detail behind that sentence, because the interesting cases are the ones that are not a tidy one-page PDF — a photo of a paper bill, a twelve-page scan, an invoice typed into the body of a message, a vendor statement. ## The three ways in They all reach the same pipeline. An uploaded file is turned into the message an emailed invoice would have produced, and from that point nothing downstream can tell the two apart. | Way in | What it is | Use it when | | ------------------ | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **Upload** | The **Upload invoice** button on [Inbox](/app/inbox) | You already have the file. Nothing has to be arranged first, which is why it is the fastest way to start | | **Intake address** | An address on your own subdomain of `inlet-ap.com`, such as `ap@yourcompany.inlet-ap.com` | This is the steady state. The vendor sends, and the invoice is in the queue with nobody doing anything | | **Forwarding** | Your existing AP mailbox, auto-forwarded to an intake address | Vendors who have never heard of inletAP keep writing to the address they have always used | Most workspaces end up using all three. See [intake addresses](/docs/intake-addresses) and [email forwarding](/docs/email-forwarding) for the two email doors. One thing an upload does not carry: the dialog does not ask which mailbox the file belongs to, so an uploaded document is filed under your workspace-wide intake mailbox. If you use per-property mailboxes so that a building is decided by the address an invoice arrived at, an upload gets no such hint and you code the building on the document. See [per-property mailboxes](/docs/per-property-mailboxes). ## The file types Twenty extensions. It is the list an upload is checked against, and it is the list the pipeline can turn into text, so it is what to send whichever door you use. | Kind | Extensions | | ------------------- | -------------------------------------------------------------- | | Portable and images | `.pdf`, `.jpg`, `.jpeg`, `.png`, `.heic`, `.tif`, `.tiff` | | Word processing | `.doc`, `.docx`, `.odt`, `.rtf` | | Spreadsheets | `.xls`, `.xlsx`, `.ods`, `.csv` | | Presentations | `.ppt`, `.pptx`, `.odp` | | Other | `.epub`, `.txt` | On an upload the decision is made on the **extension**, not on what your browser says the file is. That is deliberate: browsers report `application/octet-stream` for a `.heic` photo, for an OpenDocument file and for anything else they do not recognize, so trusting the declared type would refuse real invoices. Mail is not gated the same way — an attachment arrives, is kept, and is read if anything can read it, which is the next section. **There is no archive on that list.** A `.zip` of this month's invoices is refused on upload and is a review-queue entry when it arrives by email. Send the invoices as files. ## The size ceiling **20 MB**, and the same number at both doors, so a document too large to email us is not quietly acceptable through the other one. - **An upload over 20 MB is refused** with the file named and the limit stated. The browser checks it first, so most of the time you are told before anything is sent. - **An email over 20 MB is refused at the door**, permanently, and the sender gets a bounce. There is nothing in inletAP to find afterwards, so the sender's own bounce message is the record. The usual causes are a scanned lease, a photo set from a site visit, and a long forwarded chain with every attachment still attached. Ask for the invoice as its own message. The email limit is on the **whole message**, not on one attachment, so five 5 MB scans in one email is over the line and five separate emails is not. ## What happens to a file it cannot use | What you sent | What happens | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | An extension not on the list, uploaded | Refused on the spot, with the accepted list in the message. No document is created | | An extension not on the list, emailed | The mail is accepted and the attachment is kept. If nothing can read it, the document goes to [Review Queue](/app/review) with the reason recorded | | An empty file, uploaded | Refused. A zero-byte file would become a document with nothing in it, sitting in review forever | | Over 20 MB | Refused, as above | | The same file twice, uploaded | Refused with "This file has already been uploaded". The check is on the bytes, so a renamed copy is still the same file | | A great many uploads in one hour | Refused with "Too many documents ingested in the last hour. Try again shortly." The ceiling sits far above real AP volume | The second row is the one worth reading twice. A file nothing could open is **not** treated as "this was never an invoice" — it goes to a person, with the reason attached, because a file we could not read is a question rather than a judgment. Documents judged not to be invoices at all — newsletters, auto-replies, bounces, calendar invites — are a different case and land in the filtered tab. See [why hasn't my invoice appeared?](/docs/invoice-not-appearing). ## A multi-page PDF Sent whole, read whole. A twelve-page invoice with the detail on pages three to eleven is one document, not twelve, and the lines on the later pages are read with the rest. The one limit is on **scans**. When a PDF carries no usable text — it is a picture of a page rather than a page — the pages themselves are shown to the extraction model, and that is capped at twenty pages. A scanned PDF longer than that goes to the review queue with the reason recorded rather than being read in part. A text PDF of any length is not affected by that cap. If a single message carries several invoices as separate attachments, you get **one document per attachment**, all sharing the email they arrived in. Small inline images — the signature logos and tracking pixels on almost every business email — are indexed but do not become documents. ## A photograph of a paper bill Supported, and common. JPEG, PNG, TIFF and HEIC are all on the list, and HEIC matters because it is what an iPhone camera produces by default: it is converted to JPEG before anything looks at it, so you do not have to. A photograph has no text layer, so it is read visually rather than parsed. Two things can send one to a person instead: - A conversion that fails — a corrupt HEIC, usually. - An image too large for the model to accept, either in bytes or in pixels. A modern phone photo is nowhere near that, but a stitched panorama of a desk full of invoices is. Both are recorded as the reason on the review-queue entry rather than being silently turned into a page of empty fields. For a better read: fill the frame with the invoice, get the whole page in, and take one photo per bill. ## An invoice in the body of an email Handled. Every message's body is read and stored alongside whatever was attached, so a vendor who types "Please pay $412.50 for the June service call" instead of attaching anything still produces a document. When a message carries no attachment worth extracting, the body **is** the document. The body also travels with every document extracted from that message, so a covering note that names the building helps an invoice that does not. ## A spreadsheet Accepted — `.xls`, `.xlsx`, `.ods` and `.csv` are all on the list, and a spreadsheet is a normal way for a vendor to send a line-item breakdown or a statement. One thing to keep apart: a spreadsheet **of invoices** is not a way to load invoices in bulk. Each file becomes one document, and inletAP will try to read one invoice out of it. If what you want is your buildings, units, vendors and ownership entities loaded from a spreadsheet, that is a different job — see [importing your data](/docs/importing-your-data). ## A statement rather than an invoice A vendor statement is a list of invoices you already have, with a total at the bottom. inletAP recognizes the shape of one and cancels every duplicate rule for it, so it does not report your own invoices back to you as copies. What it does **not** do is keep a statement out of your approval queue. Nothing stops a statement being approved and posted as a bill, so the safe move is to reject it rather than leave it waiting for somebody to approve by reflex. The useful part of a statement is the gap: if it lists an invoice you never received, search the vendor, find the missing one and ask them to send it. See [duplicate detection](/docs/duplicate-detection). ## What counts against your plan The billable unit is a document that reaches extraction, and it is counted at that step whichever door the file came through. A document filtered as not an invoice never reaches extraction and has never counted. On the free plan, documents beyond the monthly allowance are received and parsed but held rather than extracted, and released when you upgrade or when the period rolls over. See [plans and limits](/docs/plans-and-limits). ## Where to go next - [Quickstart](/docs/quickstart) — one real invoice, all the way through, in about fifteen minutes. - [Intake addresses](/docs/intake-addresses) — how the addresses on your subdomain work. - [Email forwarding](/docs/email-forwarding) — pointing your existing AP mailbox at one. - [Why hasn't my invoice appeared?](/docs/invoice-not-appearing) — when something you sent is not in the list.