Accounts payable is the highest-volume keyboard task in most SAP Business One finance teams. Supplier invoices arrive as PDF attachments, scanned paper, and portal downloads. Somebody opens each one, finds the matching purchase order, checks whether the goods were receipted, keys the header and every line into an A/P Invoice, works out which tax code applies, chases the buyer when the price does not agree, and files the original somewhere it can be found again at audit.
When volume rises, the queue does not get faster — it gets later. Invoices sit unposted past the period they belong to, so accruals are estimated instead of measured. Early-settlement terms lapse because nobody could get the document approved in time. And occasionally the same invoice is paid twice, because there is no check that stops a supplier's re-sent copy from being keyed again under a slightly different reference.
ECOSIRE builds a document capture and A/P automation add-on for your SAP Business One installation that removes the keying and leaves the judgement with your team. It is build-to-order: we scope your document set, chart of accounts, tolerance rules and approval structure, quote a fixed price, then build and install it. There is no shrink-wrapped download and no free trial — the app is written for your company database.
Intake and staging
We wire up the intake channels you actually use: a monitored mailbox, a watched folder or network share, an SFTP drop, or an upload screen inside SAP Business One. Every inbound file is hashed and staged in a User-Defined Table with its original bytes retained, so the source document is always retrievable next to the posted transaction. The hash gives you the first line of duplicate defence before a single field is read.
Extraction
The capture layer reads header and line data from the document: supplier identity, document number and date, currency, net and tax totals, purchase order references, item descriptions, supplier part numbers, quantities and unit prices. Supplier resolution runs against Business Partner master data (OCRD) using tax registration number, bank details, or the sending domain, rather than fuzzy name matching alone. Line items resolve to your item codes through Business Partner Catalog Numbers, so a supplier can keep calling the part whatever they like.
Each extracted field carries a confidence value. You set the threshold per field during scoping. Anything below it routes to a human instead of guessing, and the operator's correction is fed back so the same layout is read better next time.
Two- and three-way matching
This is where the time is actually saved. The add-on matches the captured invoice against open Purchase Orders (object type 22) on price and quantity, and — where you receipt goods — against Goods Receipt POs (object type 20) as well. Tolerances are configurable by absolute amount, percentage, supplier and item group, and are evaluated at line level and at document total.
Matched lines are posted. Lines outside tolerance are held with a reason code: price variance, quantity variance, no purchase order, receipt not yet posted, closed order line, or unrecognised item. Non-PO and expense invoices follow a separate lane with G/L distribution rules, and can carry project, cost centre or other dimension coding.
Approval before posting
SAP Business One approval procedures only fire for documents created through the client UI, so an add-on that writes through the Service Layer or DI API silently bypasses them. We do not pretend otherwise. Approval is implemented as a pre-posting stage in a User-Defined Object queue, with routing by amount, supplier, cost centre or exception type, delegation, and a full decision history. The A/P Invoice is only created once the document is approved, which means your posted ledger contains no half-approved paperwork.
Posting into SAP Business One
Approved documents are created through the Service Layer PurchaseInvoices endpoint with BaseType, BaseEntry and BaseLine references back to the purchase order or goods receipt, so consumption is correct and base documents close as they should. Freight and other charges land in the document's additional expenses rather than being smeared into unit prices. Tax codes are determined by the rules agreed at scoping, including withholding tax where your localisation uses it. User-Defined Fields on the A/P Invoice record the source file, the extraction confidence, what it matched against, and who approved it — so the audit trail is inside SAP, not in an email thread.
Exceptions and visibility
The exception console is a SAP Business One screen, not a separate portal. It shows the original document image beside the extracted values, the matching evidence, and the actions available: correct and re-match, split, reassign, request a credit, or reject back to the supplier. A Crystal Reports pack covers capture throughput, exception ageing by reason code, match variance by supplier, and duplicates blocked.
Architecture and compatibility
Built as an SAP Business One add-on plus a service component: Service Layer (REST) for document creation and master data reads, DI API where an object is not fully exposed on the Service Layer, and UDTs, UDFs and UDOs for staging, configuration and the approval queue. Compatible with SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or on your hosted infrastructure. The OCR component can be deployed on-premise where your policy requires that documents never leave your network; we confirm that choice in scoping because it changes the build.
Who it is for
Companies posting enough supplier invoices that one or more people spend most of a day keying them; businesses with genuine PO discipline that want the match enforced rather than eyeballed; groups running several company databases who want the same rules applied in each; and finance teams under audit pressure to show the original document attached to every posting.
How delivery works
A scoping call and document review — we ask for a representative set of real supplier invoices, your tolerance and approval rules, and your tax and G/L conventions. From that we issue a fixed written quotation with the build scope and lead time stated. On acceptance we build, typically over one working week depending on the document variety and approval complexity. We install into your test company database first, run your invoices through it with you, adjust extraction and tolerance rules against real results, and only then install into production alongside a cutover plan. You receive the source code, the configuration workbook, and a defined post-go-live support window agreed in the quotation.
What this is not
It is not a hosted invoice bureau, and it is not a system that pays suppliers on its own. Payment stays in your hands. It will not read a document that a person cannot read either, and we will tell you during scoping which of your supplier layouts are likely to need a human touch rather than promising a number we cannot stand behind.