Spendwise: Engineering an Expense Workflow Where Every Approval Is Provable

Auditability usually costs friction. Every extra control, whether a second approver, a signed form, or a reconciliation step, buys traceability by making the process slower and more annoying to use. We built Spendwise because we did not accept that trade, and we have been running our own company on it for a year.

The Technical Problem: No Single Source of Truth

Manual management of corporate benefits and expenses has one structural flaw: there is no state and no transactionality.

Our own process ran on isolated Excel files and message threads. The cost was not primarily time, since validating a request by hand takes about a minute and the volume was manageable. The cost was correctness. A cell updated in the wrong copy of a spreadsheet, or an approval agreed in a conversation and never written down, is enough to pay the same invoice twice. There was no authoritative answer to the question of whether something was approved, by whom, and when. There was only a set of artifacts that mostly agreed with each other.

That is a state management problem, not a productivity problem. It is also the kind of problem that gets worse silently: nobody notices the missing audit trail until someone asks for it.

Architecture and Automation: Resilient Invoice Intake

Spendwise is built on Next.js as a monolith. This is a deliberate choice that keeps iteration fast and deployment simple, and that a single team can operate without a platform organization behind it. The interface is mobile-first responsive, so an employee submits an expense from a phone without installing anything.

Invoice intake is handled by computer vision (VLMs and OCR) orchestrated through n8n, an open-source automation engine. An automated intake run takes roughly 5 seconds and lands the extracted data in the request without a human touching it. Across a year of production use, 95% of submissions complete this path with no manual correction.

The remaining 5% is where the engineering matters. Financial pipelines cannot fail silently, so we set explicit confidence thresholds in the extraction prompts. When extraction confidence falls below threshold, or a technical failure occurs anywhere in the automated validation, the system routes the request to the user or the technical team with the failure surfaced. No invoice is dropped, and no request stalls in an undefined state.

Duplicate submission, the failure mode that motivated the whole project, is handled at intake. Every invoice is fingerprinted with a hash derived from amount, date, and merchant. If a matching hash already exists, the request is refused at submission and the user is told why. The duplicate never enters the workflow, so it can never reach an approver or a payment run.

The Contextual Filter: Rejection as a Feature

Most invoice tooling stops at extraction: it reads the document and hands you the fields. Extraction alone does not answer the question a finance team actually has, which is whether this expense should have been submitted at all.

Spendwise applies a contextual filter on top of extraction. Beyond categorizing the expense, itemizing the receipt, and validating the corporate tax ID, the model evaluates each submission against both the company’s line of business and its expense policy. Two examples from our own deployment:

• A restaurant invoice dated late on a Sunday evening is rejected automatically. The extraction succeeds and the receipt is valid, but the timestamp places it outside any plausible working context.
• An invoice from a legitimate supplier is rejected when line-item analysis finds personal purchases mixed into an otherwise valid business expense. The filter reads the itemization, not just the total.

In both cases the reasoning is attached to the request rather than delivered as an opaque verdict, so the employee sees exactly which rule the submission failed and can correct or contest it. The same pass generates a standardized request title and a written description of every validation performed, so an approver reading the request weeks later sees what the system checked and what it concluded.

None of these rules are hardcoded to our business. They are configuration, and adapting them to a client’s policy and sector is the first thing we do in a new deployment.

State Machine and Access Governance

To eliminate the ambiguity of the spreadsheet era, the platform’s workflow logic is centralized in an explicit state machine. Requests move through defined states, including Draft, Submitted for Approval, Approved for Payment, Rejected, Concluded and Cancelled. No request transitions arbitrarily. Every transition has a defined trigger, a defined actor, and a recorded timestamp.

Notifications are derived from the state machine rather than bolted alongside it. A transition that requires approval notifies exactly the people who can grant it, which is why a year of production use has produced no parallel email thread chasing approvals.

Authentication and authorization run through SSO, natively integrated with Azure AD. The platform inherits the management groups that already exist in the company directory, so permission structures are mapped once rather than rebuilt by hand and maintained in parallel. The same integration adapts to other identity providers such as Okta or Google Workspace.

Data Locality: Invoices Stay Where You Put Them

Expense automation normally means shipping your company’s financial documents to a third-party AI provider. We did not want that for ourselves and we do not assume clients want it either.

At Lynxmind, Spendwise runs entirely on local models. Invoices are stored in a self-hosted Supabase deployment, with a storage layer written against an interface rather than a vendor, so S3 or any other backend is a configuration change rather than a rewrite. The model layer is equally pluggable: local models, a private endpoint, or a public API, chosen by the client rather than imposed by the product.

For a company evaluating whether AI-assisted finance tooling is compatible with its data policy, this is the difference between a procurement conversation and a non-starter.

Impact: Immutability and Audit Evidence

A year in production at Lynxmind, with around 40 users and roughly 10 requests per week, has produced the outcomes we designed for: no duplicate payments, an unambiguous approval record, and the disappearance of the side-channel coordination that used to surround every request.

The underlying mechanism is a set of strict audit tables that create an immutable record of who approved what, and when. Records are appended, never edited. The history of a request is reconstructable end to end, including automated decisions and the reasoning behind them.

We want to be precise about what this means for compliance, because the industry generally is not. SOC 2 and ISO 27001 are organizational certifications covering controls, policies, and evidence collection across a whole company, and no software product confers them. What Spendwise does is produce the approval and access evidence those audits ask for, in a form an auditor can accept, without a manual evidence-gathering exercise every cycle. If your organization is pursuing either standard, Spendwise is designed to be an asset in that process rather than a gap in it.

Build vs. Buy

Spendwise took four engineers six months of continuous work, roughly two engineer-years before any maintenance. That figure is the honest build-versus-buy anchor, and it does not include the year of production hardening that followed: the failure modes we found, the threshold tuning, the edge cases in intake.

We own the code, so the delivery model is the client’s decision: self-hosted on your infrastructure, hosted by us, or something in between. Our team handles configuration and extension, adapting the state machine to your benefits regime and approval hierarchy.

Payment execution stays with the system you already use. Spendwise integrates with SAP so that an approved request flows into your existing financial pipeline rather than creating a second one, and the same integration pattern applies to any other ERP or accounting platform.

What We Are Looking For

Spendwise is proven inside Lynxmind and ready for its first outside deployment. We are looking for one partner, ideally a Portuguese SME, to run it in production, and we are absorbing the setup and customization cost entirely.

We are not looking for a pilot user to generate a logo for a website. We want a company with real approval complexity, because that is what will tell us which parts of the state machine are genuinely general and which parts are ours. In exchange, you get a configured, auditable expense workflow and direct access to the team that built it.

If that describes your finance operation, we should talk.