How BC’s Invoice Capture feature uses AI document recognition to convert vendor invoices into draft BC purchase invoices without manual data entry, the configuration and tolerance settings Finance must own, the validation workflow that ensures captured invoices are reviewed before posting, and the five AP automation failures that introduce errors faster than the manual entry they replaced.
What BC Invoice Capture Does—The Actual Workflow
BC’s Invoice Capture (available from BC 2022 Wave 2 and expanded in each subsequent wave) uses Azure AI Document Intelligence to extract structured data from scanned or PDF vendor invoices. The extracted data creates a draft purchase invoice in BC that Finance reviews and approves before posting. The workflow has five stages Finance must understand before configuration:
Invoice Capture Workflow—Five Stages Finance Owns and Manages
- Invoice Ingestion—Getting Invoices Into Invoice Capture
- Invoices enter Invoice Capture through three channels: email-based capture (vendors email invoices to a configured Microsoft 365 mailbox connected to Invoice Capture, which automatically picks up PDF attachments), manual upload (Finance uploads PDF or image files directly to the Invoice Capture workspace in BC), and scanner integration (physical invoices scanned and directed to the Invoice Capture inbox).
- Finance configures which channels are active and which email address or folder is monitored. The configuration of the ingestion channel is where most implementations start—and where many discover that their vendor invoice process requires adjustments before automation can work: vendors who email invoices to multiple recipients, invoices that arrive embedded in email bodies rather than as PDF attachments, and scanned invoices that are too low-resolution for AI recognition all require process changes before Invoice Capture can handle them.
- AI Document Recognition—What BC Extracts and How Accurately
- Azure AI Document Intelligence reads the ingested invoice and extracts: vendor name, vendor address, invoice number, invoice date, due date, currency, subtotal, tax amount, total amount, and line-level detail (description, quantity, unit price, line amount). Extraction accuracy varies significantly by document quality and consistency: a vendor who always sends the same-format PDF invoice with clear fields will achieve very high extraction accuracy. A vendor who sends scanned hand-written invoices, or PDFs generated from older accounting systems with unusual layouts, will achieve lower accuracy requiring more human correction.
- Finance must verify extraction accuracy for its top vendors before committing to the automation workflow. Run 20 invoices from the organization’s highest-volume vendors through Invoice Capture in the sandbox environment and review the extraction results field by field. The accuracy rate for these vendors determines whether Invoice Capture is a time-saver or a time-shifter for the AP team.
- Vendor Matching—Connecting the Captured Invoice to the BC Vendor Record
- After extraction, Invoice Capture must match the extracted vendor name to an existing vendor record in BC. The match is based on the vendor name extracted from the invoice against vendor names in BC’s vendor master. Exact matches post automatically to the matched vendor. Partial or ambiguous matches are flagged for Finance review—Finance selects the correct vendor from a list of potential matches. New vendors (vendors whose name does not match any existing BC record) require Finance to either create a new vendor record or map the invoice name to an existing vendor record for future automatic matching.
- Finance configures the vendor mapping rules in Invoice Capture setup: for each vendor whose invoice name differs from their BC vendor name (abbreviated names, trading names, parent company names on invoices from subsidiaries), Finance establishes the mapping so that future invoices from that vendor match automatically without Finance intervention.
- Finance Review—The Human Checkpoint Before the Draft Becomes a Purchase Invoice
- Every captured invoice must pass through Finance review before it becomes a draft purchase invoice in BC. The Invoice Capture review workspace shows the captured invoice image alongside the extracted fields. Finance reviews each field, corrects any extraction errors, confirms the vendor match, assigns the G/L account or item code for each line, and confirms the purchase invoice is ready to be created in BC. Finance can reject captured invoices (routing them back for re-capture or manual entry) or mark them as ready to create. When Finance marks an invoice as ready, BC creates the draft purchase invoice in the AP module.
- The review step is not optional in the standard Invoice Capture workflow—every invoice goes through Finance review before becoming a draft in BC. The automation value is in the pre-population of the draft, not in bypassing the review. Finance should not configure Invoice Capture in a way that skips the review step or routes invoices directly to posting without Finance confirmation.
- Purchase Invoice Processing—The Standard AP Workflow From Draft to Posted
- After Finance creates the purchase invoice from the captured draft, it follows the standard BC AP workflow: approval routing through the BC purchase invoice approval workflow (if configured), three-way match against the purchase order and receipt (if PO-based), and posting by the AP coordinator. Invoice Capture ends when the purchase invoice is created in BC—the subsequent approval and posting steps are the standard AP process, not the Invoice Capture process. Finance must ensure the standard AP approval workflow is configured before enabling Invoice Capture, because Invoice Capture accelerates the volume of invoices reaching the AP module, and invoices entering the AP module without an approval workflow means more invoices posting without authorization.
The Configuration Decisions Finance Must Own
Invoice Capture’s configuration in BC is managed through the Invoice Capture setup (Finance → Purchase → Invoice Capture → Setup). Finance owns three categories of configuration decisions that determine whether Invoice Capture produces reliable output.
Confidence Thresholds
Invoice Capture assigns a confidence score (Low, Medium, High) to each extracted field based on how clearly the AI could read the value from the document. Finance configures whether low-confidence extractions are flagged for mandatory Finance review or whether all extractions regardless of confidence level go to review. Finance should configure: any field with a low-confidence extraction must be highlighted in the review workspace so Finance pays particular attention to that field. High-confidence extractions for frequently-used vendors can be trusted more readily; low-confidence extractions for any vendor should be verified against the original invoice before creating the draft purchase invoice.
Amount Tolerance Settings
Invoice Capture compares the extracted invoice total to the expected total from the matched purchase order (if PO-based). Finance configures the tolerance within which the two amounts are considered a match. A tolerance that is too narrow produces frequent false mismatches from rounding differences. A tolerance that is too wide allows material discrepancies to pass without Finance review. Finance should set the amount tolerance at the lower of: the organization’s AP materiality threshold, or the maximum variance that could result from legitimate rounding on any vendor’s standard invoice format. For most mid-market BC environments, a tolerance of GBP/USD 5.00 or 0.5% of invoice total (whichever is smaller) is appropriate as a starting point.
Default G/L Account and Dimension Mapping
Invoice Capture can use vendor-level default G/L accounts and dimension values to pre-populate the expense coding on captured invoice lines. Finance configures these defaults on the vendor card: a software vendor’s invoices default to the Software Subscriptions expense account, a facilities vendor’s invoices default to Facilities Maintenance, a utilities vendor defaults to Utilities. The default is overridable during Finance review but pre-populating it reduces the review time for invoices from established vendors. Finance must keep these defaults current as vendors change the types of goods and services they provide.
Vendor Mapping Rules
When a vendor’s invoice name differs from their BC vendor record name, Finance must configure a mapping rule that tells Invoice Capture to associate the invoice name variant with the correct BC vendor. Common scenarios: a parent company’s name appears on invoices from a subsidiary vendor, a vendor’s legal name differs from their trading name on invoices, a vendor has rebranded since their BC vendor record was created. Unmapped name variants require Finance to manually select the vendor during review for every invoice—an overhead that compounds with volume. Finance reviews the unmatched invoice queue monthly and creates mapping rules for any vendor with three or more unmatched invoices.
Five AP Automation Failures That Introduce Errors Faster Than Manual Entry
⚠️ Invoice Capture Enabled Without a Purchase Invoice Approval Workflow—Volume Increases Without Controls
Finance enables Invoice Capture to handle the organization’s AP volume of 180 invoices per month. Invoice Capture processes ingested invoices into draft purchase invoices in BC. Because the purchase invoice approval workflow was not configured (it was in the “Finance will configure post-go-live” category from the implementation scope), draft purchase invoices created by Invoice Capture are available for immediate posting by the AP coordinator without any approval requirement. In the second month of Invoice Capture use, the AP coordinator processes 180 purchase invoices into the system. Forty-three of the 180 are for amounts above the organization’s purchase authorization threshold of £2,500. All 43 are posted without authorization. The monthly AP run pays the 43 invoices. Finance discovers the control gap during the quarterly internal review when it reviews all posted purchase invoices above £2,500 for approval evidence and finds none for the Invoice Capture-created invoices.
Fix: The purchase invoice approval workflow must be configured and tested before Invoice Capture is enabled for production use. Invoice Capture accelerates invoice volume into the BC AP module; the approval workflow is the control that ensures that increased volume is appropriately authorized. The sequence is: configure approval workflow → test approval workflow in UAT → enable Invoice Capture. Not the reverse. Finance confirms that the approval workflow routes every purchase invoice above the authorization threshold to the appropriate approver before any Invoice Capture-processed invoice can be posted. The approval workflow is not optional for Invoice Capture environments; it is the mandatory companion control that makes the automation safe.
⚠️ Wrong Vendor Matched by Invoice Capture—Invoice Posted to the Wrong Vendor Account
The organization has two vendors with similar names: “Apex Facilities Management Ltd” and “Apex Facilities Cleaning Services Ltd.” Invoice Capture extracts “Apex Facilities” from an invoice and matches it to “Apex Facilities Management Ltd” with medium confidence. The invoice is actually from “Apex Facilities Cleaning Services Ltd.” The Finance reviewer approves the vendor match without verifying it against the invoice because medium confidence matches are presented in the review workspace in the same visual format as high-confidence matches. The purchase invoice posts to the wrong vendor account. The AP aging shows “Apex Facilities Management Ltd” with an unexpected balance. When the facilities cleaning vendor calls about the overdue invoice, Finance investigates and discovers the mismatched posting. Correcting it requires a credit memo against the wrong vendor and a new purchase invoice on the correct vendor.
Fix: Finance configures Invoice Capture to require mandatory Finance review confirmation for all vendor matches with medium or low confidence, with a visual indicator that makes medium/low confidence matches immediately distinguishable from high-confidence matches. Finance trains the AP review team to verify the vendor match against the original invoice image for every medium-confidence match—not to approve it because the name looks right. Finance also creates explicit vendor mapping rules for both “Apex” vendors so that Invoice Capture learns to distinguish them based on the full vendor name. For organizations with multiple vendors sharing a partial name, the vendor mapping rules are the permanent configuration that prevents recurring mismatches.
⚠️ Invoice Capture Extracts the Wrong Invoice Date—Open Items Age Incorrectly and VAT Period Is Wrong
A vendor’s invoice PDF includes both a document date (the date the invoice was generated) and a service delivery date (the period the service was provided). Invoice Capture extracts the service delivery date as the invoice date rather than the document date. The service delivery date is two months earlier than the document date. Finance reviews the capture and approves it without noticing the date discrepancy because the invoice image is small in the review workspace and Finance does not zoom into the date fields. The purchase invoice posts with the service delivery date as the invoice date. The invoice’s due date (calculated from the posting date) is two months earlier than it should be, making the invoice appear overdue immediately after posting. The VAT period for the invoice is also two months earlier than the correct period, producing a VAT return adjustment when Finance identifies the error during the next VAT reconciliation.
Fix: Invoice date is a Finance-critical field that Finance must verify for every captured invoice—not just the invoices with low-confidence flags. Finance configures the Invoice Capture review workspace to display the invoice image at sufficient zoom to read the date fields clearly, and trains the AP review team to explicitly verify the invoice date against the document date on the invoice image as part of every review. Finance also configures BC to alert when a captured invoice date is more than 30 days in the past relative to today’s date—this flag surfaces potentially incorrect date extractions for Finance attention without requiring Finance to scrutinize every date on every invoice.
⚠️ G/L Account Defaults Not Maintained—Captured Invoices Post to Outdated Expense Accounts
When Invoice Capture was configured, the organization used three expense account codes for its main vendors: Software (GL 7100), Facilities (GL 7200), and Professional Services (GL 7300). G/L account defaults were set on the vendor cards accordingly. Eight months after go-live, Finance restructured the chart of accounts: GL 7100 was renamed and split into SaaS Subscriptions (GL 7110) and On-Premise Software (GL 7120), and GL 7300 was renamed Legal Fees (GL 7310) and Consulting (GL 7320). The G/L account defaults on the vendor cards were not updated to reflect the restructure. For six months after the COA change, Invoice Capture pre-populates captured invoices from software vendors with GL 7100 (the old account) and from professional services vendors with GL 7300 (the old account). The AP review team approves the drafts without correcting the account codes because the default looks familiar. Six months of vendor invoices post to deprecated GL accounts, producing trial balance variances that Finance investigates during the year-end close.
Fix: G/L account defaults on vendor cards must be updated whenever the chart of accounts changes. Finance adds “Update vendor G/L account defaults” to the COA change procedure: whenever a G/L account is renamed, split, or deactivated, Finance reviews all vendor cards that carry a default for that account and updates them to the correct replacement account before the change takes effect. Finance also runs the “Review vendor posting defaults” analysis quarterly: pull the active vendor list with their G/L account defaults and confirm each default maps to a current, active account in the correct account category. An annual pass through vendor G/L defaults catches the drift that accumulates between COA changes.
⚠️ Duplicate Invoice Submitted via Email and by Post—Both Captured and Paid Without Duplicate Detection
A vendor sends an invoice by email (captured by Invoice Capture’s email ingestion channel) and also sends a physical copy by post that the AP coordinator scans and uploads manually to Invoice Capture. Invoice Capture processes both copies and creates two draft purchase invoices for the same invoice number from the same vendor for the same amount. The AP review team processes both drafts across two review sessions three days apart without noticing they are duplicates. Both purchase invoices post. Both are included in the vendor payment run. The vendor receives double payment. When the vendor’s accounts receivable team identifies the overpayment and contacts Finance, Finance must issue a credit note and pursue recovery of the duplicate payment from the vendor.
Fix: BC’s purchase invoice posting validation includes a duplicate invoice check: if a purchase invoice with the same vendor, same external document number (vendor invoice number), and same amount as an existing posted invoice is submitted for posting, BC warns that a potential duplicate exists. Finance must ensure this duplicate check is enabled and that the AP review team understands that the warning requires investigation before proceeding. Finance also configures a process for managing dual-channel invoices (invoices that may arrive via email AND by post): any invoice received by post for an established vendor with an email relationship should first be checked in Invoice Capture’s capture queue before scanning and uploading. If the invoice is already in the queue, the physical copy is filed without processing. This process check eliminates most duplicate capture scenarios before they reach the AP module.
Do This / Don’t Do This
Do This
- Configure the purchase invoice approval workflow before enabling Invoice Capture—not after
- Test Invoice Capture accuracy on 20 invoices from your highest-volume vendors in sandbox before committing to production
- Configure visual indicators that distinguish medium/low confidence vendor matches from high-confidence matches in the review workspace
- Train the AP review team to explicitly verify invoice date, vendor match, and line amounts against the invoice image for every captured invoice
- Update vendor G/L account defaults whenever the chart of accounts changes
- Enable BC’s duplicate invoice detection and confirm AP team understands the duplicate warning requires investigation
- Create vendor name mapping rules for any vendor whose invoice name differs from their BC vendor record name
- Track Finance review acceptance and rejection rates monthly—a high rejection rate signals extraction quality problems that need configuration attention
Don’t Do This
- Enable Invoice Capture before the purchase invoice approval workflow is configured and tested
- Allow draft purchase invoices created by Invoice Capture to post without Finance review
- Approve medium-confidence vendor matches without verifying against the invoice image
- Treat Invoice Capture as full automation—it is accelerated data capture with Finance review, not touchless posting
- Neglect to update vendor G/L account defaults when the chart of accounts changes
- Ignore the duplicate invoice warning from BC’s posting validation—it always requires investigation
Up Next:
Invoice Capture addresses the AP workflow. The next post addresses a Finance configuration context that the series has not yet covered specifically but where BC is used widely: BC for Manufacturing—Finance Configuration That Actually Works—how manufacturing companies must configure BC’s costing, production order accounting, and inventory valuation differently from distribution and service businesses, the WIP accounting mechanics that Finance must understand even when Operations runs production, the standard cost update process Finance must own annually, and the five manufacturing Finance configuration failures that produce cost variances Finance cannot explain to the auditor.
— Bobbi
D365 Functional Architect · Recovering Controller
Thank you for reading!
If this post helped you solve a real problem, share it with a Finance colleague who is in the middle of an ERP implementation or a post-go-live optimization. If you have a topic that I haven’t covered, please reach out. There is always one more post worth writing.
Interested in learning more? Below are some of my latest posts:
Leave a Reply