Automating Invoice Intake and Reconciliation with Object Storage, SAP and SQL

Most finance teams do not lack systems. They lack a governed path between them. Supplier invoices land in a shared bucket or container, someone downloads them, keys values into a spreadsheet, looks up the purchase order or open item in SAP, checks a reconciliation table in a SQL database, and emails a colleague when something does not match. Each step is reasonable. The sequence is fragile, slow and almost impossible to reconstruct later.

The failure is rarely a single bad calculation. It is the seams: a file processed twice, a tolerance applied differently by two people, an exception approved in a chat thread with no link back to the invoice. When an auditor asks why a payment was released, the answer is spread across a mailbox, a spreadsheet and a memory.

This guide describes a pattern that keeps the systems you already run and puts the sequence into one Nexus workflow. The file store, SAP and the reconciliation database stay where they are. What changes is that the handoffs, decisions and exceptions become steps in a single execution record.

AWS S3 and Azure Blob Storage are both listed Nexus trigger sources. When a new invoice file lands in the agreed location, the trigger starts a workflow run with the object reference as input. Nothing depends on a person opening a folder, and nothing is processed twice because the run records which object it handled.

Other storage options, including GCS, MinIO and FTP or SFTP, are also listed trigger sources, which matters in estates where supplier files arrive through older channels. The pattern is the same: the storage event starts the work, and the run owns what happens next.

The first steps are deliberately boring. Confirm the file type, check the naming convention, reject anything outside the agreed format with a recorded reason, and move on. Most of the value of automation in finance comes from applying these small rules the same way every time.

• 01New object in AWS S3 or Azure Blob Storage starts the run
• 02File type and naming checked by rules
• 03Duplicate handling based on the recorded object reference
• 04Rejected files routed with a reason, not silently dropped

Structured invoices, such as e-invoicing formats or CSV exports, can be parsed deterministically with Rules + Code. Nexus supports code nodes in Python, Bash, Go, Java, .NET, PHP, PowerShell, and JavaScript or TypeScript through Deno, so the parsing step can use the language and libraries your team already maintains.

Unstructured PDFs are where a self-hosted model can help. An extraction or classification step can propose supplier, amount, currency and reference values, with the model running inside your deployment boundary. The proposal is an input to the next step, not a decision. Values below a confidence threshold, or values that fail validation, go to review rather than onward.

This split is important for governance. Deterministic rules handle what is known. The model handles ambiguity. A person handles the remainder. Each of those contributions is recorded separately, so a reviewer can see which values came from the document, which from the model and which from a human correction.

SAP is part of the Nexus actions library, and reading an invoice from SAP is available as a pre-built SAP operation. Where the process needs a function that the prebuilt action does not cover, the generic SAP RFC node can call BAPI and RFC functions that your SAP system exposes and that your SAP team has approved.

The run looks up the related purchase order or open item and brings back only the fields the reconciliation needs. It does not assume a universal SAP data model, because every SAP landscape has its own configuration. The mapping is defined for your process and versioned with the workflow.

Write-back follows the same principle. If the process ends with a posting or status change, that step runs only after validation and, where policy requires, approval. The SAP call, its input and its response are part of the execution record.

Many organisations keep reconciliation data outside SAP: a data warehouse table, an older finance database or a supplier ledger. Nexus includes MSSQL and Oracle DB nodes, so the workflow can query the approved reconciliation source directly under a scoped, vault-backed credential.

Rules + Code then compares the three views: what the invoice says, what SAP holds and what the reconciliation source expects. Tolerances, currency handling and rounding rules live in the workflow rather than in someone's head, and changing them produces a new workflow version rather than an undocumented change in behaviour.

Matched invoices proceed. Mismatches are classified by reason, such as missing purchase order, amount outside tolerance or supplier mismatch, so that the reviewer sees a specific question rather than a generic failure.

Exceptions are where finance risk sits. The workflow pauses on an unmatched or out-of-tolerance invoice and presents the reviewer with the file, the extracted values, the SAP record, the reconciliation row and the reason the rules stopped. The reviewer approves, corrects or rejects, and that decision is recorded with their identity and timestamp.

The run then resumes under policy. An approval can continue to write-back. A correction can re-run validation. A rejection can notify the supplier-facing team. None of those outcomes leaves the execution record, which is the point: the decision and the action share one history.

Approval thresholds are a policy choice. Some teams approve every exception. Others approve only above an amount or for new suppliers. The workflow expresses the rule, and the rule is visible.

After the run, an auditor or controller can see which file started it, which values were extracted and how, which SAP and SQL lookups were made, which rules applied, who approved an exception and what was written back. That is a practical definition of evidence: enough to reconstruct the decision without interviewing the people involved.

Because Nexus runs on-premises, in private or sovereign cloud, or air-gapped, the invoices, the model and the record can all stay inside the boundary you control. Nexus provides 1,480+ pre-built actions across 43 product families. Additional operations can use APIs, protocols, databases or Rules + Code in the same governed run.

The result is not a new finance system. It is the missing layer between the systems you already trust.