OpenFinance: Agentic B2B Supplier Portal

• 

  Human approval for submitting a document

• 

  AP portal overview

Inspiration

In my experience working in the B2B payment and commerce space I’ve seen many buyer portals and frustrated suppliers spending valuable time on repetitive manual work just to get paid. The obvious way to automate that is to connect the systems directly, but that creates another problem: those integrations are costly to build, hard to maintain, and often only make sense for the largest suppliers. They also tend to break when portals change.

The moment I heard about WebMCP, this was the first problem that came to mind. It felt like a natural fit for something that had always been painful to solve. It also felt like a strong fit for human-agent collaboration. This is financial data moving between businesses, so the agent can handle the repetitive work while people stay involved where review, approval, or judgment is needed.

What it does

OpenFinance is a B2B supplier portal with WebMCP built in.

It lets a supplier’s AI agents work directly with the portal through 12 governed WebMCP tools, handling tasks like submitting invoices, resolving exceptions, providing evidence, opening cases, tracking payments, keeping finance systems up to date, and more.

The goal is to remove repetitive portal work, save finance teams time, and keep the human operator in the loop, with a human-in-the-loop approach wherever review or judgment is needed.

How I built it

I used Codex to do the coding, infrastructure decisions, technology choices, testing, and documentation.

OpenFinance was built as a working authenticated supplier portal. I suggested Vercel and Supabase, and Codex helped choose the rest of the stack: Next.js and TypeScript, deployed on Vercel, with Supabase for authentication and PostgreSQL for persistence.

The portal exposes 12 WebMCP tools covering invoice submission, validation, exceptions, evidence, cases, status, and payments. The tools use the supplier’s existing signed-in browser session and call secure backend routes.

The frontend shows information and collects human decisions, while the important financial rules, permissions, supplier isolation, validation, and state changes are enforced on the backend.

For sensitive actions like submitting invoices or evidence, the operator gets a clear approval screen before anything is sent.

I also built a separate supplier-side reference app for the demo so I could show the full workflow across two independent systems, with the agent acting as the bridge between them.

Challenges I ran into

The main challenge was making the app work like a real finance workflow rather than a basic tool in short time. These portals are full of follow-up steps. Submitting an invoice alone was not enough.

I also wanted to make the difference between WebMCP and browser automation very clear - The agent is using structured tools exposed by the portal, not just clicking through pages.

Accomplishments that I'm proud of

I don't come from a coding background, so getting this working end to end is something I'm especially proud of.

I built a real workflow across two separate systems without creating integration between them which is really cool. The same agent can submit work into the buyer portal, understand what comes back, take follow-up actions, and keep the supplier's system updated.

What I learned

It is not enough for an agent to take an action. It also needs to bring the right information back to the human, present it clearly, and keep the company’s systems up to date.

I also saw how WebMCP could help with a much broader B2B problems: getting different systems to work together without building and maintaining another custom integration.

What's next for OpenFinance

The long-term goal is bigger than one portal. OpenFinance can be a supplier portal of its own, but also act as a WebMCP bridge to other buyer portals that do not support WebMCP yet.

That would let suppliers use the same agent across both WebMCP-enabled portals and legacy portals, while giving older portals a more generic path to become agent-ready without each supplier building another custom integration.

Over time, that could grow into a network where agents can work across many buyer portals through one common model.

About the demo - how it was made

The agent panel is a visualization. I created it this way because I felt it made the flow much easier and faster for a new viewer to understand what was happening behind the scenes across two separate systems.

Every WebMCP tool call, argument, result, approval, and application state shown was captured from a live execution against the deployed portal. All demonstrated tools and workflows are fully functional in the live application.

And I also preferred the AI voice over mine :)

Contest note

The contest submission is the Acme AP supplier portal. The supplier invoice system shown in the demo and repo is a separate reference application used to demonstrate the full workflow.

Built With

• chatgpt
• codex
• supabase
• vercel