BILL Inbox Not Processing Invoices? Diagnose the Intake Path

BILL has more than one workflow. The AP inbox is for vendor bills and invoice intake. Accounts Receivable is for invoices you send to customers. Spend & Expense has card, reimbursement, and receipt workflows. If a vendor invoice was sent toward an AR or Spend & Expense path, it may not appear in the AP review queue you expected.

BILL pricing and product pages describe Accounts Payable features such as managing bills from a centralized inbox, entering bills, automating approval workflows, paying by ACH, card, credit card, and other methods, and connecting with vendors through the BILL network. Those features are downstream of the correct AP path. A document sent into the wrong product area can look like an extraction failure when the first issue is simply destination choice.

Multi-entity setups add another layer. BILL announced a Multi-Entity Inbox update in June 2026 that allows one parent-level email address and inbox for related entities while preserving individual entity-level workflows when needed. If your organization uses multiple entities, verify whether the invoice should go to the parent-level intake path or an entity-level path before assuming BILL lost it.

AP invoice: use the AP inbox or document destination shown for the right organization or entity. Customer invoice: do not expect an AR workflow to create an AP bill review item. Spend receipt or reimbursement: diagnose inside BILL Spend & Expense rather than AP.

A BILL inbox address should come from your own BILL account, your administrator, or current BILL guidance. Avoid public examples, remembered formats, screenshots from a prior implementation, or addresses copied from a different entity. A plausible-looking address can still send the invoice outside the workflow you are trying to diagnose.

Check the exact recipient on the original email, including aliases, display names, and forwarding contacts. A saved contact can hide an old address behind a friendly label. Also check whether the original email was forwarded as a normal email or attached as an .eml or .msg file. If BILL expects the invoice document as a file attachment or document upload, wrapping the whole message as a mailbox attachment can keep the actual invoice from being available in the expected way.

Use the current BILL Help Center and your own account settings for exact inbox setup paths and email-format limits. Those details can vary by product area and account configuration, so copy the destination from the workflow you are actually diagnosing instead of relying on a public address pattern.

Copy the destination from current BILL account settings or a BILL administrator. Inspect the raw recipient in the sent email, not just the contact display name. Replace stale entity-level destinations if your company moved to a parent-level Multi-Entity Inbox.

Vendor direct-send is useful only when the vendor sends to the right intake destination and your company policy supports that pattern. Some vendors keep using a buyer, owner, or bookkeeper address. Others send portal notifications that contain no invoice attachment. Some billing portals allow only one billing contact, so changing the address can affect operational notices as well as invoices.

Do not confuse vendor direct-send with BILL Network behavior. BILL developer documentation describes the BILL Network as a collection of vendor and customer organizations using BILL, where connected vendors can receive payments through their set payment method. That network relationship is about connected organizations and payments. It does not prove that a vendor emailed a usable invoice document to your AP inbox.

If a vendor says they sent the invoice, ask for the exact sent-to address, timestamp, and attachment name. If they sent only a link, download the actual invoice before routing it. If they sent a statement, order confirmation, quote, credit memo, or payment reminder, decide whether it belongs in AP review before sending it again. The inbox problem may be that the email is not an invoice.

Vendor sent to a person: route from that inbox or update the vendor billing contact. Vendor sent a portal notice: retrieve the invoice file before expecting AP intake to extract it. Vendor is connected in BILL: still confirm the invoice document entered the right AP path.

BILL developer documentation separates attachments from bill documents and lists a 6 MB file-size limit for v3 API uploads of vendor attachments and bill documents. That is API-specific evidence, not a universal email or web-upload limit. Use current BILL Help Center or in-product guidance for the channel you are testing.

The practical diagnostic is still straightforward. Confirm the invoice is attached as a normal document, is not password-protected, is not a ZIP full of unrelated files, and is not only an image embedded in the email body. If the invoice is inside a portal, login page, or download link, BILL may receive the email but not the source document needed for AP review. Send a clean invoice file through the supported BILL path before debugging extraction.

File shape also affects automation before BILL. Expensent supports PDF, JPG, and PNG attachments for invoice classification, extraction, and forwarding. Confirm BILL support before routing another file type automatically.

Use the current BILL Help Center or in-product limits for email and upload paths. Avoid portal-only, password-protected, corrupted, or wrapped email-message attachments. Test with one clear invoice document before broadening mailbox or vendor rules.

After a document arrives, BILL still has to complete intake and field capture. BILL product pages describe AI-powered AP automation for capturing invoices, routing approvals, processing payments, and syncing with accounting software. They also describe BILL AI and invoice coding capabilities, but the troubleshooting point is narrower: extraction is a processing step, not the same as approval or payment readiness.

That means extraction is not the same as approval. A document can be accepted but need a preview, a vendor match, coding review, an entity choice, or manual correction before it becomes the bill you expected. BILL developer documentation says uploaded attachments can take a few minutes before the upload process and preview generation are complete. If the document is in a temporary processing state, repeated sends may create confusion instead of speed.

When extraction looks wrong, compare the original invoice against the fields BILL captured. Check vendor identity, invoice number, invoice date, due date, amount, line items, memo, currency, and entity. Low-quality images, mixed documents, statement packets, credit memos, and documents from a new vendor can require finance review even when the file arrived correctly.

If the document appears but fields are wrong, correct the bill rather than re-forwarding blindly. If the document is still processing, gather evidence before sending another copy. If several documents are delayed, check BILL status and support guidance before changing setup.

Expensent finds current and historical invoice emails and sends selected documents to the BILL destination configured for the correct organization or entity.

Confirmed sender-and-subject patterns can route new recurring invoices automatically. Portal notices and unusual messages remain visible when they need attention.

BILL continues with extraction, coding, approvals, payments, vendor setup, and accounting sync.

Escalate with evidence instead of a vague missing-invoice report. For the email layer, collect sender, recipient, sent time, subject, attachment names, file types, and any bounce or spam evidence. For the BILL layer, collect the target company or entity, product area, inbox or document destination used, whether the document appears anywhere in BILL, and what status or field result you see.

Route the escalation to the right owner. The email administrator owns provider forwarding, sender authentication, security filtering, and attachment stripping. The BILL administrator owns account setup, AP inbox configuration, entities, users, roles, approval policies, vendor setup, and payment permissions. BILL support owns product behavior once the current official guidance and account configuration have been checked.