The Agentic Invoice Workflow: From Generation to Reconciliation

The invoice workflow at scale is three distinct operations. Generation. Dispatch. Reconciliation. The first two have been half-automated for years through Stripe, QuickBooks Online, and the vendor stack. The reconciliation step is where AR teams still do meaningful manual work. This post covers how the Meow agentic invoice workflow closes the loop end to end, from the agent's first prompt through the reconciled entry in the general ledger.

The AR Team's Problem

Accounts receivable is a three-step operation. Draft the invoice, deliver it to the customer, and match the incoming payment to the outstanding invoice when it lands.

The first two steps are largely solved. Invoicing software has automated drafting and delivery for a decade. Templates, branding, PDF generation, and email dispatch are commodity capabilities.

The third step is where the operational work sits. The customer pays across ACH, wire, card, or USDC. The payment lands in a bank account or a wallet address. The AR clerk (or the accounting integration) has to match the payment amount to the outstanding invoice, tag the payment to the customer record, and sync the entry to the general ledger with the right revenue category.

This matching step is the reconciliation gap. It is where finance teams spend the most manual work on receivables. The Meow agentic invoice workflow closes the gap.

How the Agent Generates an Invoice

The invoice generation flow runs through the same MCP endpoint the rest of the agentic banking stack uses.

The agent calls the invoice creation tool with the customer identifier, the amount, a description of the work or product, the optional payment terms (Net 30, Net 60, Due on Receipt, or a custom notional), and the entity the invoice is billed from. For multi-entity operators, the entity selection matters. An operator running five LLCs bills each customer from the LLC the work was performed under, not from a portfolio-wide default.

For a typical consulting invoice, the agent prompts the operator: "Which customer, which amount, and what is the description?" The operator answers. The agent calls the tool, populates the invoice with the operator's entity branding data (company name, logo, address, EIN), and generates the PDF.

The invoice number is auto-incremented per entity. Each entity maintains its own invoice series, which keeps the audit trail clean across the multi-entity portfolio.

Invoice Branding and Customer Delivery

The invoice PDF carries the entity's branding. Company name, logo, remittance address, invoice number, line items, payment terms, and the payment options the customer can use.

The payment options are configured per entity. An entity that accepts ACH and wire only will surface those two rails on the invoice. An entity that also accepts USDC will surface a wallet address for on-chain payments alongside the traditional rails. An entity with a card acceptance configuration will surface a hosted payment page URL for card payments.

The invoice ships to the customer's email address (provided by the operator or the agent at invoice creation) as a PDF attachment plus a link to the hosted invoice page. The hosted page carries the payment options and the "mark as paid" acknowledgment surface. The customer can pay directly from the hosted page or forward the invoice to their AP team for processing.

Email delivery uses the entity's configured send domain. Operators who have not configured a custom domain send from Meow's default invoicing subdomain. Deliverability follows the standard email authentication chain (SPF, DKIM, DMARC).

Payment Capture Across Rails

The Meow agentic invoice workflow supports payment capture across four rails.

ACH is the standard rail for domestic B2B invoicing. The invoice surfaces the entity's ACH details; the customer initiates the transfer from their bank. When the funds land in the Meow account, the workflow matches the incoming ACH against the outstanding invoice by amount and by memo field (which is populated with the invoice number by default).

Wire is the rail for large-notional invoices where the customer requires wire specifically. The invoice surfaces the wire instructions; the customer initiates the wire from their bank. Match logic runs on the amount and the wire memo field.

USDC is the on-chain rail for stablecoin-denominated invoices. The invoice surfaces the entity's wallet address on the chain the operator selects (Ethereum, Base, Solana, or Arbitrum). The customer sends USDC to the wallet address; the workflow matches the incoming transfer against the outstanding invoice by amount and by chain.

Card is the rail for smaller invoices where the customer prefers card. The invoice surfaces a hosted payment page URL; the customer completes the payment on the page. Card acceptance carries the standard card processing fees, which are typically covered by the customer for B2B invoices and by the invoicing entity for B2C.

Across all four rails, the payment lands in the Meow account associated with the invoicing entity. The workflow tags the payment to the specific invoice and updates the invoice state to paid.

Reconciliation to the General Ledger

The reconciliation step is where the workflow closes the loop.

The invoice payment lands in the Meow account, and the workflow syncs the entry to the customer's configured accounting integration. The QuickBooks API integration is the most commonly used; Xero and NetSuite are also supported.

The sync writes the paid-invoice entry to the AR module of the accounting system. The invoice number matches. The customer record matches. The revenue category matches the category the entity configured at invoice creation. The AR clerk sees the reconciled entry in the accounting system without doing the reconciliation manually.

For payments that come in across the underlying financial messaging standards, the ISO 20022 message data carries the invoice reference through the settlement layer. The ISO 20022 standard is the messaging framework that governs the payment initiation, clearing, and settlement messages that most bank rails use. The invoice reference embedded in the ISO 20022 message travels with the payment through the rails and is available at reconciliation.

Multi-Entity Invoice Streams

Multi-entity operators run separate invoice streams per entity. Each entity carries its own invoice numbering series, its own branding data, its own accepted payment rails, and its own accounting integration route.

The multi-entity dashboard surfaces the invoice streams per entity, alongside the consolidated view of outstanding receivables across the portfolio. The multi-entity portfolio operations post covers the broader multi-entity surface; the invoice stream is one of the per-entity resources that lives inside that surface.

The AI agent operating a multi-entity portfolio disambiguates the entity at invoice creation the same way it disambiguates on other transactional operations. If the operator asks the agent to "send the invoice for the consulting engagement," the agent asks which entity the invoice is for. The operator picks. The invoice is created against the correct entity's stream.

The Invoice Lifecycle States

Every invoice on a Meow account follows the same lifecycle states.

Draft. The invoice is created but not yet sent. Useful when the operator wants to review the invoice before dispatch. The draft is not visible to the customer.

Sent. The invoice has been dispatched to the customer. The customer receives the email and the hosted page URL.

Viewed. The customer has opened the hosted page. The state transition is tracked via a pixel on the hosted page.

Paid. The customer has completed payment across one of the accepted rails, and the workflow has matched the payment to the invoice.

Reconciled. The paid-invoice entry has synced to the accounting integration. The general ledger reflects the receivable.

Void. The invoice has been canceled by the operator. The customer receives a void notification. Useful when the operator needs to reissue with corrected details or terminate the invoice for another reason.

Each state transition is logged in the audit trail alongside the wire, ACH, card, and payment operations the customer-configured control plane covers. Operators reviewing an unusual invoice can see which state transitions occurred, when, and (for agent-initiated transitions) which agent initiated them.

Frequently Asked Questions

How does an AI agent send invoices through Meow? The agent calls the invoice creation tool through the MCP endpoint with the customer identifier, the amount, the description of the work or product, the payment terms, and the billing entity. The agent generates the invoice PDF branded with the entity's data, dispatches it to the customer's email as an attachment plus a link to the hosted invoice page, and tracks the state transitions from draft through reconciled.

Which payment rails can customers use to pay a Meow invoice? Four rails are supported: ACH for standard domestic B2B invoicing, wire for large-notional or wire-required settlements, USDC on Ethereum, Base, Solana, or Arbitrum for stablecoin-denominated invoicing, and card for smaller invoices where the customer prefers card. The operator configures which rails are accepted per entity.

How does the reconciliation to my accounting system work? When the invoice payment lands in the Meow account, the workflow syncs the paid-invoice entry to the customer's configured accounting integration (QuickBooks Online, Xero, or NetSuite) automatically. The invoice number matches the entry the AR module already carries; the customer record and revenue category flow through with the sync.

Can each of my entities have its own invoice stream? Yes. Multi-entity operators run separate invoice streams per entity, each with its own numbering series, branding, accepted payment rails, and accounting integration route. The multi-entity portfolio operations post covers the broader surface.

Does the AI agent handle payment reminders? The agent can send configurable reminders to customers who have not paid an invoice on the configured terms. Reminder cadence and content are customer-configured; the default is one reminder at the invoice due date and a second reminder past due. The customer can suppress reminders entirely per invoice or per customer.

What happens if a payment lands without a matching invoice? The workflow surfaces the unmatched payment in the reconciliation review queue. An AR clerk or the operator can manually match the payment to an invoice through the dashboard. Common causes are payments made without the invoice memo (which most banks allow at customer discretion), payments for multiple invoices netted together, and prepayments made before an invoice was issued.

How are the invoice operations audited? Every invoice creation, dispatch, state transition, and reconciliation event is logged with the agent identifier (or the dashboard user), the invoice ID, and the timestamp. The audit trail is the same surface the customer-configured control plane post covers, unified across wire, ACH, card, USDC ramp, and invoice operations.

Try It Yourself

If you have a Meow account today, the invoice creation flow runs through the dashboard invoicing panel for human-issued invoices and through the MCP endpoint for agent-issued invoices.

For an agent-issued invoice on Claude, ChatGPT, Cursor, or Gemini, the agent calls the invoice tool with the customer, the amount, the description, the payment terms, and the billing entity. The invoice generates as a PDF branded with the entity's data, ships to the customer's email as an attachment plus a hosted page URL, and tracks the state transitions from sent through reconciled.

If you are coming to Meow for the first time, the LLC walkthrough covers the account setup that the invoicing surface sits on top of.

Apply at meow.com.

Banking services are provided by Grasshopper Bank, N.A., Member FDIC.