Building Payvy in public: what exists today, what does not, and what is next

This is the first entry in a build log we will keep while Payvy is in development. The point is simple: say what exists in the source today, say what does not, and let the record show whether we did what we said next. If you only read one older post, read Introducing Payvy for the direction; this entry is the current inventory behind it.

What exists in the Rust core today

Reviewed against the source as of November 10, 2026:

• Document and email intake. Invoices arrive by upload or inbound email into a document inbox. Originals are stored in your configured S3-compatible object store — self-hosters choose and operate that storage.
• Model extraction. An Anthropic backend and an OpenAI-compatible backend extract draft fields from invoices. Drafts are checked for arithmetic and matched to vendor records. Quality depends on the document and the model; there is no accuracy guarantee.
• Vendor workflows. Named approvers, amount thresholds, timed holds, and external signals, with each bill retaining the workflow version it started with. Agents can propose a workflow; a person accepts it.
• One command system, two doors. The REST API and the MCP server expose the same command registry. Agent credentials can prepare bills and propose work; person-only commands — approving and releasing payment among them — are excluded server-side, not merely hidden in a UI.
• Mercury payments. A person previews and confirms release, Mercury executes (ACH, checks, domestic wires, and real-time payments), and Payvy tracks status, including failures and returns. Request mode adds an approval inside Mercury; direct mode relies on the person-authorized release in Payvy.
• An audit record. Changes are recorded as events, and commands run inside organization-scoped transactions with Postgres row-level security.

What does not exist yet

Being explicit, because comparison pages elsewhere on the internet will not be:

• No hosted web product to sign up for. The interactive previews on this site use sample data. Hosted Payvy, with the planned $39 bring-your-own-agent and $99 managed-agent company pricing, is in development; timing and managed AI allowances are not announced. See pricing.
• No accounting or ERP sync. VisiBooks, QuickBooks Online, Xero, and the listed ERP connections are planned. Nothing syncs to your books from the current build.
• No purchase-order matching or procurement suite. Planned, not implemented.
• One bank. Mercury is the implemented payment connection. Additional banks and non-USD currencies are planned.
• Coarse agent permissions. The current boundary is actor type (agent vs. person). Per-agent, task-scoped permissions and spending policies are planned — the design direction is in agent controls.

What we are building next

In product terms: the hosted web approval experience that the homepage previews, accounting connectors starting with the planned QuickBooks Online and Xero work, and the agent task workspace with evidence, assignments, and durable state across disconnects. Order and timing will be reported here as they firm up, not promised in advance.

How to follow along

• Star or watch the Rust source on GitHub — the repository is the ground truth behind every claim in this log.
• Try the sample approval workflow to see the experience we are building toward.
• Tell us what your AP workflow needs at support@payvy.com. Design-partner conversations shape the build order more than any roadmap document.

The next build-log entry will report what changed in the source since this inventory. If nothing shipped, it will say that too.

Payvy is in development under AGPL-3.0-only. “In the source” means implemented in the reviewed Rust build; it does not mean the hosted product is generally available.