BillForge

A modular multi-tenant accounts payable platform: invoice capture, approval workflows, vendor management, and reporting, with a Rust/Axum backend and a Next.js interface.

Rust
Axum
Next.js
PostgreSQL

BillForge invoice list with synthetic vendors, amounts, and statuses — Open full-size screenshot or illustration

Recorded walkthrough

BillForge walkthrough: 35.08 seconds. Text walkthrough.

Written walkthrough

Recorded walkthrough (local instance with synthetic data): 1. Start signed in to a synthetic organization and browse the invoice list. 2. Open TSI-78234 and review its vendor, amount, dates, purchase order, and notes. 3. Approve one pending invoice; the pending queue decreases from four to three. 4. Open Reports and review the Cash Flow Obligations panel for the synthetic invoice set. The capture uses an isolated development build with local setup fixes; some other report panels are unavailable. No payment is completed in this recording.

Synthetic invoice list with status and amount fields. Open full-size screenshot

Invoice detail with synthetic vendor, amount, dates, and notes. Open full-size screenshot

Pending invoice approvals in the synthetic organization. Open full-size screenshot

Cash Flow Obligations panel with sample payment commitments. Open full-size screenshot

What it is

BillForge automates the accounts payable lifecycle from document capture through approval: a multi-tenant SaaS platform where each module - invoice capture, processing, vendor management, reporting - can be enabled per organization, with tenant-scoped data access.

The problem it solves

Accounts payable teams live in a loop: receive invoices, key them in, chase approvals, answer “where is it” questions, and reconcile at the end of the period. Off-the-shelf tools handle slices of this; BillForge was built to own the whole loop in one system with clean boundaries between modules.

My contribution

I designed and built the platform end to end: the Rust/Axum API with per-tenant isolation, the module architecture, the Next.js interface, and the workflow engine that routes invoices through configurable approval pipelines.

Architecture

Backend: Rust with Axum behind an API gateway; JWT authentication and tenant-context middleware protect module routes.
Modules: invoice capture, processing, vendor management, and reporting, each independently enableable per organization.
Frontend: Next.js with React Query and Zustand.
Storage: PostgreSQL with a multi-tenant schema.

Engineering decisions

Modular monorepo over microservices. Modules are separated by boundary but deployed together, which keeps a solo-maintained product operable while preserving the option to split later.

Tenant isolation at the middleware boundary. Authenticated module requests carry tenant context before they reach module logic, so feature handlers receive the tenant context needed for isolation checks.

Workflows as data, not code. Approval pipelines are configured per organization rather than hardcoded, which is what makes per-tenant enablement of the processing module possible.

Stack

Rust, Axum, Next.js, TypeScript, PostgreSQL, Tailwind CSS.

The walkthrough above runs against a local instance with a synthetic organization, vendors, invoices, and users. The portfolio does not host an accounting backend.