DocumentQ User Guide: Overview & Getting Started
This section is the actual manual — what BDP DocumentQ – AI AP Automation does, in the terms you’ll see on screen, one topic per page. Start here for the shape of the whole thing; the pages after this go deep on each piece.
The idea in one line
The vendor’s invoice is a claim. Your purchase order and posted receipt are the truth.
DocumentQ uses AI to read the claim, then Business Central logic compares that claim against your own records. On a purchase-order-backed invoice, the purchase invoice that finally reaches your ledger is built by Business Central’s own Get Receipt Lines — quantities come from the posted receipt, prices come from the purchase order. The extracted claim is used to check that document and to decide whether a person needs to look at it, not to write it.
That is why a wrong number on a vendor’s PDF can cause an exception, but cannot cause a wrong posting on a reconciled document.
The five stages every document goes through
| Stage | What happens |
|---|---|
| Capture | The invoice PDF is read and turned into a structured claim — vendor, invoice number, dates, totals, lines. |
| Identify the vendor | Tax registration number, GLN, bank IBAN, then name similarity — in that order of trust. |
| Reconcile | Claimed lines are matched to the purchase order and the posted receipt, within your tolerances. |
| Decide | Either the document is Ready, or it is an Exception carrying a specific reason code. |
| Register | Business Central builds the purchase invoice from your own PO and receipt lines. A person posts it. |
Three things worth knowing up front
No per-vendor templates or training. Extraction is semantic, not coordinate-based, so a vendor’s first invoice is handled the same way as their hundredth, and a layout change does not require reconfiguration.
On a PO-backed invoice, the figures come from your records, not the PDF. A wrong number read off the invoice can raise an exception; it is not used to build the document. An invoice with no purchase order behind it has nothing to check against — see invoices with no purchase order, which describes the different, clearly marked path those take.
Every exception carries a stable reason code — such as ERR-QTY-OVER — plus the specific factor rows behind it. Not a confidence percentage, and not a narrative written by a model. The full list is in the reason code reference.
DocumentQ never posts to your ledger on its own
DocumentQ can build a Business Central purchase invoice for you — this is called registering. Posting is always a separate, human action, and where approval routing applies, DocumentQ actively blocks posting until the document has been approved.
There is no setting that makes DocumentQ post automatically. Unattended processing can register a fully reconciled document without a click; it does not post one.
What you’ll meet in this manual
| Page | What it covers |
|---|---|
| Setting up DocumentQ | The six setup steps, in order, and the optional configuration worth doing once you are running. |
| Getting invoices in | The three routes an invoice can arrive by, and the duplicate protection every one of them runs through. |
| The triage workflow | The thirteen statuses, what each one means, and what you do next in each. |
| Resolving an exception | The four routes out of an exception, and which screen resolves which kind. |
| Invoices with no purchase order | The manual coding path, why approval is mandatory on it, and how it stays marked afterwards. |
| Approvals | Routing through Business Central’s own approval framework, and the three things that usually go wrong. |
| Unattended processing | The scheduled cycle, and the two switches touchless registration needs. |
| Where your documents are stored | The three storage modes, what genuinely differs between them, and how to choose. |
| Privacy and data handling | Exactly what leaves your Business Central environment, and what is kept. |
| Permissions and roles | The three permission sets and who each is for. |
Before you start
You don’t have to read this manual in order, but it assumes you already have the concepts from the Learn section — what matching an invoice against an order and a receipt actually proves, what a tolerance is, and why duplicate invoices are the failure everyone underestimates. If any of that feels unfamiliar, those pages cover it in plain language before this manual starts using it as product vocabulary.
If you’d rather skip the explanation and just do something, go straight to process your first invoice.
A word on scope
Present-tense statements in this manual describe how the shipping version of DocumentQ is designed to behave. Where a capability is designed but not reachable yet, the manual says so plainly rather than describing a roadmap as if it were already true — the FAQ states the current boundary directly, and it is worth reading before you plan a workflow around something this manual does not confirm is live.
Exact wording of page captions and field names may differ slightly between versions. The privacy statement and end-user licence agreement govern in case of any difference with these pages.