BILL Inbox Not Processing Invoices? Diagnose the Intake Path

When an invoice is missing from BILL, resist the first instinct to send it again. Duplicate sends can create extra review work if the first message is still processing, went to another entity, or already became a bill in a different view. Start by locating the break point: did the email leave the sender, reach the right BILL intake destination, create a document, extract into bill fields, route to approvals, or stop before payment review?

Build a short evidence trail from the original message. Capture the sender, recipient address, sent time, subject, attachment names, file types, and whether the message was sent by a vendor, a mailbox rule, Expensent, or a user forwarding manually. Then compare that evidence with the expected BILL product area and entity. Most failures are not mysterious AP failures. They are intake-path mismatches.

If multiple otherwise valid submissions fail at once, check BILL System Status before changing rules. Treat status as a live troubleshooting step: an incident or maintenance window can explain a sudden cluster of failures, while a healthy status page points you back to destination, entity, file, and workflow checks.

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.

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.

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.

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. If a vendor sends another file type, Expensent may still surface the email for review, but teams should confirm BILL support before routing that file type automatically.

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.

Some reports of a BILL inbox not processing invoices are actually approval or payment issues. The invoice is in BILL, but it is not in the approver queue, payment list, accounting sync, or vendor record the user expected. At that point, stop debugging email intake and move into AP workflow review.

BILL developer documentation describes approval policies as rules that control which bills require approval, by whom, and when. If approval policies exist and a bill matches a policy, the bill response can include approvers and approval-flow status. That means the policy, bill amount, approver group, entity, user role, or bill coding can explain why a document did not follow the expected path.

Payment is a separate boundary. BILL AP payment documentation describes funding, disbursement, timing, status tracking, bank account verification, vendor setup, and payment operations. A bill can be entered or approved without being ready to pay, and a payment can be blocked by funding, vendor, bank, MFA, permissions, or timing requirements. Expensent does not change any of those BILL controls.

Expensent belongs before BILL in this diagnostic path. BILL manages AP after documents arrive. Expensent helps make sure the right vendor emails and attachments get there with review. That distinction matters: it prevents blind forwarding while keeping BILL as the system for extraction, approvals, payments, vendor network behavior, and accounting sync.

In Expensent, users connect the inbox where invoice emails already arrive. Candidate invoice emails are reviewed by next action: ready to forward, download from portal, needs review, or false positive. A user can forward a selected invoice to the BILL destination they configure, or create a rule from a reviewed email pattern and subject pattern for future similar invoices.

This is strongest for email-heavy AP workflows, historical catch-up, shared inboxes, and vendors that keep sending invoices to people instead of the BILL destination. It also makes troubleshooting easier because the team can see what was found, what needed review, what was forwarded, and which items were not ready for BILL. The workflow does not replace finance judgment; it moves the intake decision earlier where it is visible.

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.