Four finance modules. One set of plumbing.

The expensive part of finance software is never the software. It is the integration — the weeks of mapping, the reconciliation of one system against another, and the standing cost of keeping them in step once the project team has gone.

FinMark.ai connects to your ERP once, over SOAP or REST. Purchase orders, goods receipts and vendor master data flow in; approved invoices and their tax fields post back out. Every module on the platform reads and writes through that same connection, so adding revenue recognition or a live P&L later is a configuration decision rather than a second integration project.

Where SharePoint is already your document repository, invoices stay there — picked up from the folders you already govern, under the access controls and retention policies you already run. Nothing has to be migrated into a new storage layer to be processed.

Group structures are handled at the same layer. Each subsidiary runs as its own isolated tenant with its own ERP instance, vendor base and approval policy, with a cross-company view above them for the people who need to see all of it.

AI that reads documents is now a commodity. AI that knows when it has read one wrong is not. FinMark Check is the layer between extraction and your finance team, and it is the part of the platform that makes the rest of it safe to trust.

Extraction runs twice, through two models that verify each other before anything moves downstream. What survives that is then checked against the things it is supposed to agree with: the purchase order, the goods receipt, the vendor master record, and the tax treatment the vendor and service category imply. Duplicates are caught here. So are the sanity failures that AI alone would wave through.

Anything that fails is held back rather than pushed through with a flag on it. This is the difference that matters operationally — a queue of held items is work; a stream of approved-but-wrong entries is a restatement.

Because FinMark Check sits under every module rather than inside one of them, the same standard applies whether the thing being validated is an invoice, a recognition schedule or a posting to the P&L.

Finance teams do not get judged on the month they had. They get judged on whether they can explain it afterwards, to an auditor who was not there and is not inclined to take it on faith.

Every entry the platform produces carries its provenance: the source document, the rule that was applied, when it was applied, and who approved it. A withholding tax deduction can be traced to the vendor attributes and regulation that produced it. A recognised revenue entry can be traced to the contract clause and the standard it was recognised under. An approval can be traced to the person who gave it and what the invoice looked like at the moment they did.

Because it is one trail across every module rather than one per tool, a question that crosses modules — why this figure in the P&L, from which invoice, approved by whom, taxed under which rule — is answerable in one place instead of reconciled across four exports.

Accounts Payable is live in production with enterprise customers today, running the full invoice-to-ERP workflow. FP&A, P&L Auto Track and RevRecog AI are in early access, rolling out with design partners.

We are telling you this on the platform page rather than letting you find out on the call, because the alternative is a buyer who stops believing the rest of the page. Every product here is built on the same connection, the same validation layer and the same audit trail — but "built on" is not the same as "in production", and the badge on each product page tells you which is which.

The practical consequence for a buyer: start with Accounts Payable, which has customers behind it, and take the rest when you want to be a design partner rather than a reference.