Accounts Receivable & Payable

Overview

Axiomatic provides full accounts receivable (AR) and accounts payable (AP) capability through two action-oriented modules — Invoicing (/invoicing) and Purchasing (/purchasing) — backed by canonical APIs at /api/invoicing/* and /api/purchasing/*.

The terminology Accounts Receivable and Accounts Payable still applies wherever it actually means the GL control accounts: trial balance, financial statements, the chart of accounts, and period-end reconciliations. The user-facing entry points and APIs use the action-oriented names because they describe what the user is doing, not which side of the ledger ends up moving.

Migration note (Plan B, 2026-05). The legacy dual entry points /ledger/ar, /ledger/ap, /api/ledger/ar, /api/ledger/ap, and /api/ledger/ap/match were consolidated onto Invoicing and Purchasing. The legacy API paths now return 410 Gone with a pointer to the canonical replacement; they will be removed entirely after one quarter.

Counterparties

Customers and vendors are managed as counterparties — every record links to a CRM companies row so relational concerns (lifecycle, contacts, addresses) live in one place and operational concerns (payment terms, 1099, AP automation) live in the relevant module. Each counterparty record carries:

• Name and contact email
• Default currency for billing
• Wallet address and blockchain network (for crypto payments)
• Tax ID (for vendors, used in 1099 tracking)

A vendor created in /purchasing/vendors and a vendor created in /crm/companies end up as the same row (companies.counterpartyId → counterparties with role = vendor or both). There is no duplicate identity.

Cross-links

Invoices (Accounts Receivable)

Creating an Invoice

An invoice includes one or more line items, each with a description, quantity, unit price, and optional revenue account mapping. You can set a due date, billing currency, and whether to accept crypto payments.

Invoice Lifecycle

Invoices progress through these statuses:

• Draft — being prepared, not yet sent
• Sent — delivered to the customer
• Partially Paid — some payment received
• Paid — fully settled
• Overdue — past the due date without full payment
• Void — cancelled

Recording Payments

When you record a payment against an invoice, Axiomatic:

1. Updates the invoice's paid amount and status
2. Emits a canonical invoicing.payment.received event
3. The posting engine generates the appropriate journal entry (e.g. DR Cash, CR Accounts Receivable)

Payment methods include ACH, wire, check, crypto, credit card, and other.

Credit memos

Credit memos are separate from negative invoices. They reduce customer balances via amount_credited on invoices when applied. Create drafts under Invoicing → Credit memos, issue them, then apply amounts to open invoices. The posting engine emits invoicing.credit_memo.* events (two-step GL: liability pool on issue, clear AR on apply). Export a printable HTML summary from the memo detail API (GET /api/invoicing/credit-memos/:id/pdf) or a CSV statement (GET /api/invoicing/credit-memos/statement?customerId=).

Crypto payments (USDC on Base)

1. Create an operating wallet under Accounting → Treasury → Operating wallet (see Treasury).
2. On the invoice, enable Accept USDC on Base (or set default accept USDC under Invoicing → Settings).
3. The invoice exposes a pay link and address for the entity operating wallet; printable PDFs can include the link.
4. Inbound USDC is matched to open invoices during on-chain sync when amount and memo align; you can still record payments manually with method: "CRYPTO" and the transaction hash.

Bank deposits: ACH/wire instructions via a Bridge virtual account settle to the same operating wallet. Configure under Admin → Receiving accounts.

Bills (Accounts Payable)

Entering a Bill

A bill records an obligation from a vendor. Each bill includes line items with descriptions, quantities, unit prices, and optional expense account mappings. Bills can be linked to a purchase order via the Match PO affordance on the bill detail page (/purchasing/bills/[id]), backed by /api/purchasing/po-match.

Bill Lifecycle

Bills follow a similar lifecycle with an additional approval step:

• Draft — being entered
• Received — bill received from vendor
• Approved — approved for payment (emits purchasing.bill.approved)
• Partially Paid — some payment made
• Paid — fully settled (emits purchasing.bill.paid)
• Overdue — past due date
• Void — cancelled (emits purchasing.bill.voided)

Paying a Bill

When you record a payment against a bill:

1. The bill's paid amount and status update
2. A canonical purchasing.bill.paid event is emitted
3. The posting engine generates a journal entry (e.g. DR Accounts Payable, CR Cash)

Debit memos

Debit memos (vendor adjustments) live under Purchasing → Debit memos and apply to bills via amount_debited. Issuing posts expense and AP; applying allocates to specific bills without a second GL entry. APIs: /api/purchasing/debit-memos. Events: purchasing.debit_memo.{issued,applied,voided}.

Crypto Payments

To pay a vendor in crypto:

1. Set payCrypto to true on the bill
2. Store the vendor's wallet address on their counterparty record or on the bill directly
3. Click Pay on the bill — this creates a payment intent and navigates to /pay
4. The Pay page confirms the details and executes the transfer from the entity's Axiomatic smart wallet via the bundler
5. Gas fees are sponsored by the Axiomatic paymaster — no ETH balance required in the wallet

Alternatively, you can record a manual crypto payment with the outgoing transaction hash.

Smart Wallet Payments

The /ledger/pay page provides a unified payment interface for on-chain payments:

• Pay a bill — select from open bills with crypto enabled
• Upload a bill — upload a received invoice (PDF/image) and enter payment details
• Send a transfer — freeform token transfer to any address

Payments are executed from the entity's Axiomatic smart wallet (Diamond pattern, ERC-4337). The platform builds a UserOperation, the paymaster sponsors gas, and the bundler submits the transaction. The user never needs to hold ETH for gas or sign with a browser wallet.

Payment intents track the lifecycle: PENDING → SUBMITTED → CONFIRMED (or FAILED / EXPIRED).

Aging Reports

AR aging (/invoicing/aging) buckets use invoice open balance after credit applications (total − paid − credited); the page also shows unapplied credit memos (issued memos not yet fully applied).

AP aging lives at /purchasing/aging and follows the same five-bucket structure, computed via the shared computeAgingReport engine.

Overdue invoices and bills are automatically flagged when their due date passes.

Customer & Vendor Ledgers

View the complete transaction history for any customer or vendor. From /invoicing or /purchasing/bills, deep-link with ?customerId= or ?vendorId= to scope the list. From the CRM company page, the View invoices / View bills cross-links land you in the right module pre-filtered.

API Reference

Accounts Receivable (Invoicing)

Accounts Payable (Purchasing)

Deprecated paths (return 410 Gone)

These stubs will be removed entirely one quarter after the cutover.