AP Invoice Capture & Automation

The problem

Accounts payable in Dynamics 365 Finance & Operations is where finance teams quietly lose days every month. Invoices arrive as PDFs in a shared mailbox, as scans from a supplier portal, and as paper someone photographs on a phone. Somebody keys them into the Vendor invoice journal or the Pending vendor invoices form. Somebody else chases the buyer to confirm the receipt happened. A price varies by fourteen cents against the purchase order line, matching status goes to Failed, and the invoice sits until month end when the accrual has to be booked anyway.

F&O ships genuine invoice-matching machinery — three-way matching policies, price and quantity tolerance percentages, matching status on the vendor invoice header and lines, and invoice approval journals. What it does not ship is the front half: getting a supplier's PDF into a structured VendVendInvoiceInfoTable record with correct lines, correct financial dimensions, correct sales tax, and a defensible audit trail of what the document actually said. That gap is where the headcount goes.

What ECOSIRE builds

This is a build-to-order engagement. Nothing here is sitting on a shelf waiting to be downloaded. After a scoping call and a fixed quote, ECOSIRE writes the extension against your environment, your legal entities and your chart of accounts, then delivers it through your LCS pipeline.

Capture and extraction

A new intake surface accepts documents from a monitored mailbox, a drop folder, or a direct upload from the AP clerk's workspace. Every document is stored against a staging record with the original binary attached through the Document management framework, so the source file never leaves the system. Extraction runs against a document intelligence service of your choosing — the extension is written with a provider abstraction so the model endpoint and credentials live in a parameters form, not in code. Extracted header fields (vendor identifier, invoice number, invoice date, currency, totals, tax amounts) and line fields (item or procurement category, description, quantity, unit price, line net) land in staging tables built as normal X++ tables with their own security privileges and duties.

Vendor resolution and posting profile

Extracted vendor identity is resolved against VendTable using a configurable ladder — tax registration number, bank account, email domain, then fuzzy name. Unresolved documents route to a human triage queue rather than guessing. Once resolved, the correct posting profile, payment terms and default financial dimensions come from the vendor record and the legal entity's parameters, exactly as a manually keyed invoice would.

Matching engine

Matched candidates are written as pending vendor invoices so that F&O's own three-way match evaluates them. On top of native price and quantity tolerances, the extension adds a rule layer you configure per legal entity, per vendor group, and per procurement category: absolute-value tolerances alongside percentages, freight and rounding allowances, tolerance for over-receipt within a window, and an under-billing rule that lets a partial invoice pass without opening an exception. Every rule evaluation is logged with the values it compared, so a controller can answer "why did this pass" months later.

Exception handling and approvals

Exceptions become work items in the F&O workflow framework. ECOSIRE builds workflow types for invoice approval and for exception resolution, with configurable hierarchy providers so routing can follow the purchasing agent, the cost centre owner via ledger dimensions, or a spending-limit ladder. Approvers act from the standard Work items assigned to me list and from the mobile-friendly workspace the extension adds, seeing the original document image side by side with the extracted lines and the PO line it was matched against.

Integration surface

All staging and configuration tables are exposed as data entities so you can load historical documents through the Data management framework, and so an external RPA or integration platform can read matching status over OData. Long-running work — batch extraction, bulk matching, retry of failed calls — runs in the batch framework with proper batch tasks so it scales across AOS instances rather than blocking a user session. Where a Power Platform front end is a better fit for supplier self-service or approver notifications, ECOSIRE wires it through Dual-write or a Power Automate connection to the same entities rather than building a parallel data store.

Build discipline

Everything is extension-based X++ — chain of command, event handlers, table and form extensions, extended data types in a dedicated model. No overlayering. Your existing customisations are not touched, and the model deploys as a standard deployable package.

Who this is for

Organisations processing enough vendor invoices that AP clerks spend more time typing than reviewing: distribution and retail businesses with high PO volume, manufacturers with frequent partial receipts, project-driven businesses where invoices carry project and category dimensions, and any group running several legal entities that wants one intake process rather than one per country.

It suits companies already live on F&O, or in an implementation where AP process design is still open. It is not a fit for organisations with fewer than a few hundred invoices a month — the manual process is cheaper than the build.

How delivery works

Scoping call. We walk your AP process end to end: document sources, volumes, entity structure, matching policy today, who approves what, and what your auditors ask for. We look at your F&O version, your existing model list, and how your LCS pipeline is set up.

Fixed quote. You receive a written scope with the exact forms, tables, entities, workflows and rules to be built, the extraction provider assumption, and a fixed price. Nothing starts until you approve it.

Build. ECOSIRE develops in a development environment — yours if you provide one, ours if you prefer. You get build check-ins with working functionality rather than status text.

Install in test. The deployable package goes into your sandbox through LCS. We configure parameters, rules and workflows with your team, and run your own invoices through it — real documents, real POs, real approvers.

Production. Once you sign off in sandbox, the same package is applied to production through your normal release process. We are on the call for the first cycle.

Support. A defined support window follows go-live for defect fixes and configuration questions, with the source code in your hands throughout.

Typical lead time from approved quote to sandbox install is two to four weeks depending on scope.