Incoming Documents in Business Central, Explained

Incoming Documents is Business Central’s own record for a file that has arrived and needs to become something — usually a purchase invoice.

It is worth understanding on its own terms, because it is the native surface DocumentQ builds on, and because people often expect it to do more than it does.

What an Incoming Document actually is

One record, holding:

• One or more attachments — the file itself, typically a PDF.
• Metadata fields — vendor, document date, amount, and so on.
• A link to the Business Central document it eventually became, if it became one.
• A status, so you can tell which arrived files have been dealt with.

You can create one by dragging a file onto the page, by emailing to a monitored address if that is configured, or programmatically.

What it gives you

A place for the file to live. The attachment is stored inside your Business Central environment, backed up with everything else, and it stays associated with the resulting purchase invoice. Six months later an auditor can open the posted invoice and get to the source PDF.

A record that a file arrived. Nothing quietly disappears into an inbox. There is a list, with a status.

A link between the file and the document. Once you create a purchase invoice from an Incoming Document, the two are connected. That link is genuinely useful and easy to under-appreciate until you need it.

What it does not give you

It does not read the file. The metadata fields on an Incoming Document are fields somebody fills in. Business Central does not open the PDF and populate them.

It does not identify the vendor. You choose the vendor.

It does not create the invoice lines. Creating a purchase invoice from an Incoming Document gives you a header. The lines are still yours to produce — from Get Receipt Lines if there is a receipt, or by hand if there is not.

It does not check anything. There is no comparison against a purchase order, no duplicate detection on file content, and no variance reporting. It is a filing cabinet with a link, not a matching engine.

A structural detail worth knowing

The attachments on an Incoming Document are a sub-record, keyed by the Incoming Document entry number and a line number — and the first attachment is not line 1. Business Central assigns line numbers in increments, so the first attachment is line 10000.

That is an implementation detail you would never care about, except that it is a classic source of bugs in extensions that assume otherwise: code that looks for “the first attachment” by hardcoding line 1 finds nothing, on every document, forever, while appearing perfectly reasonable in review.

It is mentioned here because it is the kind of thing worth asking a vendor about. An extension that reads attachments correctly will handle a document with several attachments, and will prefer the PDF over a covering image.

How DocumentQ uses it

DocumentQ always creates or links an Incoming Document. Whichever route an invoice arrives by — upload, promotion of an existing Incoming Document, or a monitored mailbox — the result is the same pair of records: a native Incoming Document holding the PDF, and a DocumentQ document holding the claim.

That means:

• The file is reachable through native Business Central surfaces, not only through DocumentQ’s own pages.
• The link between the file and the eventual purchase invoice is the native one, so nothing is lost if DocumentQ is later removed.
• If invoices already arrive in your Incoming Documents through native configuration, Process with DocumentQ picks them up from there. Nothing needs to be re-uploaded.

Where the bytes end up

By default, DocumentQ offloads the file out of the Business Central database to keep the database small, and the Incoming Document then holds a pointer rather than the bytes. That behaviour is a tenant choice with three options — see where your documents are stored.

Two rules apply regardless of which mode you choose, and both exist to prevent the same failure:

• A file that was already on an Incoming Document before DocumentQ saw it is never cleared from it. A native View or Download must never find zero bytes.
• If an offload fails — the destination is unreachable, say — the attempt is caught, an audit event is written, and the file simply stays in Business Central. Intake never fails because storage did.

When to use Incoming Documents on their own

If your invoice volume is genuinely low and every invoice is straightforward, native Incoming Documents plus Get Receipt Lines is a perfectly honest workflow. You get filing, a link, and a correctly built invoice.

What you do not get is anybody checking the vendor’s claim against your records. That is the work — and the risk — that stays with a person. See does Business Central match invoices to purchase orders?.