Getting Invoices Into DocumentQ
There are three ways an invoice reaches DocumentQ. All of them end up in the same place and run the same code — there is one intake path, not three implementations that need to agree.
Every route produces the same two things: a native Business Central Incoming Document holding the PDF, and a DQ Document (captioned AP Document) at status Received.
Upload a file
On the DocumentQ role centre, or on AP Documents, choose Upload Invoice and pick a PDF. This is the quickest way to try the product, and it has no precondition beyond an active subscription.
After a manual upload you get one of two messages, and they matter: accepted and queued for capture, or this is a duplicate — identical bytes were already received. A superseded document is deliberately excluded from the role centre tiles, so a correct duplicate detection can look exactly like a lost file if you skip the message.
The role centre’s Upload Invoice tile does not open a file dialog directly. Business Central role centre pages cannot host that kind of action, so the tile navigates to the page that carries the real upload action. This is expected behaviour, not a fault.
From a Business Central Incoming Document
If invoices already arrive into Business Central’s own Incoming Documents, open one and choose Process with DocumentQ. No vendor needs to be selected first.
The action is available on both the Incoming Documents list (where you can select several rows at once) and the Incoming Document card. The record must have an attachment; a PDF attachment is preferred, and if there is none, the first attachment of any type is used. A row that has already been promoted is skipped with a message rather than duplicated.
From a monitored mailbox
Invoices emailed to a mailbox Business Central can retrieve from are ingested through the same path as an upload. Configure the connector on DocumentQ Unattended Processing, which also reports whether this tenant currently has a working retrieval connector.
Read this before relying on the email route. The mailbox is polled by the scheduled unattended batch — the same job that drives capture — and by nothing else. There is no always-on mailbox watcher running independently of it. On a tenant where unattended processing has never been enabled, emailed invoices never appear in DocumentQ at all. If that describes your tenant and you are wondering why nothing arrives from email, that is almost always the reason.
The poll reads unread messages only, and takes PDF attachments. If a message cannot be marked as read after processing, that failure is deliberately ignored — the next cycle simply re-pulls it, and duplicate detection catches the repeat for free.
Duplicate protection
Duplicate invoices are the most common real problem in accounts payable, so DocumentQ checks for them several ways rather than once:
| Check | When | What it tests |
|---|---|---|
| Content hash | At intake | The exact bytes of this file match a document already in the system. |
| Vendor + invoice number, identical bytes | After the vendor is identified | The same vendor sent the same invoice number, and the file is byte-identical. |
| Vendor + invoice number, different bytes | After the vendor is identified | Same number, different file — treated as a possible revision, not a duplicate. See below. |
| Already posted in Business Central | After the vendor is identified | A posted purchase invoice already exists for that vendor and invoice number. |
| Same vendor, same total, nearby date | After the vendor is identified | A near-duplicate within a short window (7 days by default). Warning only — a factor row is written and nothing is blocked. |
A confirmed duplicate is marked Superseded and kept for the audit trail rather than deleted. The original stays the live one.
A re-issued invoice is not treated as a duplicate
If a vendor re-sends a corrected invoice under the same invoice number, the file content differs. DocumentQ routes it to a person as an exception rather than discarding it.
This is deliberate and it is worth understanding. Superseding a true duplicate costs nothing. Superseding a revision destroys the only correct copy of a bill somebody has to pay. Only a byte-identical re-send is superseded automatically.
The vendor-plus-invoice-number check is also re-run a second time at Register, because a lot can happen between capture and a person clicking the button.