Pantry

Outside services

The services the project declares it sends data to, each with its reason.

cloudflare

Worker hosting

mail-provider

A hosted Pantry emails sign-in links, invitations, invoices, reminders and its questions through the owner's own Resend or SendGrid account; Pantry on your own computer sends no email.

plaid

Live bank and card feeds with the owner's own Plaid keys; statement files work without it.

stripe

Card payment from the invoice link (ACH bank debit for a US Stripe account) and payouts split into sales, fees and refunds, with the business's own Stripe key.

gusto

Payrolls posted as one balanced entry, through the owner's own Gusto developer app.

xero

Move-in from Xero with attachments, through the owner's own Xero app.

ai-provider

Reading receipts and the owner's own words in answers, with the installation's own key; without one, details are typed in.

Scope and limits

What it will not do

• Paying bills or moving money from Pantry
• Tax filing or tax advice
• Running payroll (Gusto runs it; Pantry books it)
• Multi-currency
• Multi-entity consolidation
• Inventory valuation
• Depreciation automation
• Advanced revenue recognition
• A model account held by Pantry (receipts and answers are read with the installation's own AI key)

Declared limits

Status

unmeasured

Requirements

All 19 clauses of Pantry’s CONTRACT.md. They say what the project must do; the handover and verification records say what is built and tested.

PAN 19 clauses

1. PAN-01
   Set up the business The owner records the legal name, entity type, state, fiscal year start, books start date, the tax method declared with the accountant and the book/report policies; adds people with a role and grants and invites them to sign in. Each role is enforced by the server on every request, including a removed role on a live session and cross-site writes. Acceptance evidence: ledger.test.mjs › PAN-01 a business is set up with declared policies and each role is enforced by the server.
2. PAN-02
   Chart of accounts and opening balances A person starts from a small service-business chart or builds their own (one receivable, one payable and one retained-earnings control account); opening balances are a balanced draft that a second person posts. An account with postings keeps its type and role. Acceptance evidence: ledger.test.mjs › PAN-02 a chart of accounts is configured and opening balances post only after review by a second person.
3. PAN-03
   Customers, vendors and documents A person keeps customers and vendors with terms, and uploads source documents (PDF, image, text, CSV, OFX) whose exact bytes and SHA-256 are kept and returned. CAPTURE-001 to CAPTURE-007 add capture and reading on top of this store. Acceptance evidence: ledger.test.mjs › PAN-03 customers, vendors and source documents are kept, with document bytes returned exactly.
4. PAN-04
   Invoices and credits A person drafts an invoice with lines, income accounts and a sales tax code or exemption per line; a line with no tax decision stops approval. A second person approves the exact version, except the owner and ACCESS-003 atomic within-limit self-issue; automatic recurring runs, early-payment discounts, integration mappings, imported/opening sign-offs and ACCT-003 bulk write-offs retain their named approvals. Issuing posts receivable, income and sales tax. A credit for an issued invoice is approved and issued the same way and applies to that invoice. Sending, payment and follow-up are INVOICE-002 to INVOICE-005 and PAY-001 to PAY-005. Issuing limits that let a preparer issue alone within an amount the owner sets are ACCESS-003. Acceptance evidence: subledgers.test.mjs › PAN-04 invoices are drafted, approved and issued; unknown tax stops approval; credits reduce what is owed.
5. PAN-05
   Bills and evidence A person records a bill or expense with lines and posts it to payables, attaches its source document, and sees its payable status. A posted bill without a document is a close exception until a document is attached or someone with the post grant records why there is none. Acceptance evidence: subledgers.test.mjs › PAN-05 bills post to payables with their evidence; a bill without evidence is a close exception until resolved.
6. PAN-06
   Payments recorded from outside Pantry A person records a payment received or made outside Pantry (check, wire, Zelle, cash, a provider Pantry is not connected to) against a bank account and allocates it, wholly or partly, to open invoices or bills; unapplied money stays visible as a credit. Recording moves no funds. Reversing a payment reopens what it paid. Provider-backed collection and bill pay are PAY-001 and BILLPAY-001. Paying bills from a credit card or line of credit is BILL-003. Acceptance evidence: subledgers.test.mjs › PAN-06 payments made outside Pantry are recorded and allocated to open items without moving money.
7. PAN-07
   Statement import A person imports a CSV or OFX (QFX, QBO) bank statement for a named bank account. OFX must name that account; a CSV is confirmed by its last four digits. Re-importing the same file adds nothing; an overlapping download adds only new lines; a statement in the other format overlapping the same days is refused. The original file is kept. This remains the path for any account without a live feed and for history before a feed's reach (BANK-002). Acceptance evidence: bank.test.mjs › PAN-07 CSV and OFX statements import against the right bank account, and repeats create no duplicates.
8. PAN-08
   Matching A person (or an approved agent proposal) matches statement lines to ledger postings: one-to-one, one deposit split across several receipts, a fee or bank income the books lack, a transfer between accounts, a vendor payment, or a partial customer settlement. A payment already recorded is cleared by its bank line without being posted again. A match that does not balance is refused; a line or posting is matched once. Acceptance evidence: bank.test.mjs › PAN-08 statement lines match to the books through splits, fees, transfers and partial settlements, never posting a recorded payment twice.
9. PAN-09
   Reconciliation A statement reconciles only when its opening follows the last reconciled closing, its lines account for the change in balance, every line is matched, and the ledger's bank balance less items not yet on a statement equals the closing balance. Every remaining difference is listed; a completed reconciliation stores its proof and freezes its matches. Balances typed wrongly from a statement can be corrected, with a reason, before reconciliation. Acceptance evidence: bank.test.mjs › PAN-09 a statement reconciles only when its balances are proven, and every difference is explained first.
10. PAN-10
    Journals A person prepares a balanced manual entry, optionally citing a document; someone else with the post grant posts the exact revision they reviewed. Preparer, poster and approval are kept. Control accounts post only through invoices, bills and payments. Acceptance evidence: ledger.test.mjs › PAN-10 a journal entry posts balanced, approved by someone other than its preparer, for the exact version reviewed.
11. PAN-11
    Reversal A person with the post grant corrects a posted entry with a dated reversal linked both ways. Both entries stay in the ledger; an invoice is corrected by a credit instead; a matched posting must be unmatched first. Acceptance evidence: ledger.test.mjs › PAN-11 a posted entry is corrected by a linked reversal and its history survives.
12. PAN-12
    Reports Trial balance, general ledger with running balances, profit and loss, balance sheet (with calculated current and prior-year earnings) and receivables/payables aging, all from the same posted lines, with the subledgers tied to their control accounts. REPORT-001 to REPORT-008 extend these into the full reporting job. Acceptance evidence: close.test.mjs › PAN-12 trial balance, general ledger, profit and loss, balance sheet and ageing all come from the same ledger.
13. PAN-13
    Close and lock A period's checklist calculates whether every bank account is reconciled through month end, nothing is left unposted, bills have evidence, subledgers agree with control accounts, the trial balance balances, no agent proposal waits and every question Pantry asked about the month is answered (PAN-18); review tasks are completed by named people. Someone with the lock grant locks the month. A reopening is requested with a reason and approved by a different person holding the reopen grant. Acceptance evidence: close.test.mjs › PAN-13 a period closes through its checklist and lock; locked dates refuse people and agents; reopening needs an approved request.
14. PAN-14
    Leave with the books Anyone in the books downloads the accountant package for a period (entity and declared policies, close checklist, trial balance, P&L for the month and year to date, balance sheet, aging, general ledger, reconciliations with proof, reversals, approvals, notes, document index) and the general ledger as CSV. rer export and rer import restore the complete books, documents, reconciliations, close state and move-in journal into a fresh installation, refusing an archive whose posted entries do not balance. Connection credentials stay installation-local and are not in the archive (DATA-001). Acceptance evidence: close.test.mjs › PAN-14 the accountant package holds the period's reports, reconciliations, approvals and reversal history; tests/restore/restore.test.mjs export → fresh clone → rer import → rer setup → identical books and document bytes, then start over in the same folder, and a refused restore over existing books.
15. PAN-15
    Agent preparation The owner issues an agent token. The agent reads its context (unmatched lines and postings, documents marked as untrusted evidence, close status) and files typed proposals: a match, a journal entry citing its document and quoting the passages used, a close packet of exceptions, or a variance explanation citing entries. A person approves or rejects each; approval re-checks the cited records, the lock and the approver's grants. A proposal whose cited record changed becomes stale. Typed commands: node scripts/pantry-agent.mjs and [API.md](API.md). The built-in agents in AGENT-001 to AGENT-010 file the same proposal types. Acceptance evidence: agent.test.mjs › PAN-15 an agent prepares matches, entries and close work that a person approves; stale or unauthorised work never lands; the browser journey drives scripts/pantry-agent.mjs.
16. PAN-16
    Move in from QuickBooks Online or Xero exports A person uploads the seven QuickBooks Online report exports, or Xero's six standard exports (chart of accounts, contacts, sales invoices, bills, the Trial Balance and the bank accounts' Account Transactions), and the reconciled bank balance at cutover; a dry run shows counts, refused rows with reasons, tie-outs (trial balance balances, open invoices equal receivables, unpaid bills equal payables, each bank balance equals its statement, one control account each; from Xero, each bank account's transactions reach the trial balance), what does not come in and why, and missing documents. Import writes staged records through Base's import kit with its journal and originals; undo removes them while nothing has been posted; the accountant's sign-off re-checks the tie-outs and posts the opening balances, after which corrections are entries, not undo. After a Xero import, a person connects Xero (read-only invoices and attachments, with the installation's own Xero app, XERO_CLIENT_ID and XERO_CLIENT_SECRET) and the files attached to the imported open invoices and bills are kept byte for byte on those records; a file over the document limit is listed, not carried; undo removes them too. RER Managed cannot reach Xero yet and says so in one line. See [MOVE-IN.md](MOVE-IN.md). MIGRATE-001 to MIGRATE-007 add live-API move-in with history and attachments, the full Xero connection and FreshBooks. Acceptance evidence: move-in.test.mjs › PAN-16 a QuickBooks Online cutover is previewed, imported as staged records, undone or signed off by the accountant; move-in.test.mjs › XERO-001 Xero exports are previewed, imported, carry their attachments over, undone, and sign off to Xero's trial balance to the cent (Xero faked at its network edge with recorded responses). The supporting tests/api/oauth-return.test.mjs XERO-001 journey proves that a cross-site Xero return keeps the local owner signed in and connected while forged or missing state is refused.
17. PAN-17
    Receipts caught, read and attached A person takes a photo of a receipt from a phone browser or uploads a photo, PDF or saved email; on an installation with a domain on Cloudflare, the owner creates a private Pantry address on the settings page (the mailbox routed to the Worker by Email Routing plus a random tag), and receipts forwarded to it arrive on their own. Every original is kept byte for byte with its SHA-256, an email whole with its attachment beside it. With the installation's own AI model key, entered by the owner on the settings page and stored sealed, Pantry reads the vendor, date, total, tax, currency and expense account; with no key it says to add one and reads nothing. It proposes the matching bank or card line, bill, payment or entry by amount, date window and vendor, and attaches the receipt only when a person accepts or corrects what was read; accepting a line not yet in the books records it to the chosen account. A rule the owner sets (vendor, account, up to an amount) may attach a receipt that matches exactly one line. The close lists every expense paid from a bank account that has no receipt, to add one there or record why none is needed; each entry's receipts open from the entry, the report drill-down and the general-ledger CSV. RER Managed hosting has no outbound connection for AI providers or a domain for mail yet, and says so in one line. See [docs/receipts.md](docs/receipts.md). CAPTURE-001 to CAPTURE-008 and CONNECT-006 extend it to the full capture job. Acceptance evidence: receipts.test.mjs › Receipts: a phone photo is kept byte for byte, read by the install's own model, and attached to its card charge only when a person accepts; receipts.test.mjs › Receipts: an email forwarded to the private Pantry address is kept whole, read from its PDF, and a rule the owner set attaches it (model faked at its network edge).
18. PAN-18
    Pantry asks about what doesn't add up About hourly, and on request, Pantry's books agent checks the books by plain rules: a deposit nothing is matched to, money out with no category, or a cost (a bill, or bank spending filed to an expense) without a receipt or recorded reason past ages the owner sets; two payments to one vendor, or two charges from one payee, of the same amount close together; and a statement closing balance the books' opening balance plus every bank transaction cannot reach. Each finding is one question, asked once, beside its exact record, with numbered answers that each say what they change (a category with the month's net income before and after, the open invoice or bill of that amount, a transfer, the payment already recorded, a reason). New questions go to the owner by email first, a few a day, with a link to the record; replies to the Pantry address from that owner answer them (a number files it, "always" also makes a bank rule, an attached receipt is kept and attached, other words are read by the installation's own AI model key into an answer that waits for a "yes"). In the app a person with the record grant answers the same way. Nothing posts without the answer; a reason for a missing receipt needs the post grant. A question the books settle first closes itself and says why. At close the month's questions are one thread, each open one saying why it is open, and the lock waits until none is open. Without a key the rule checks still run and say so; RER Managed hosting has no outbound connection for AI providers or domain for replies yet, and says so. See [docs/questions.md](docs/questions.md). AGENT-002 extends it to other people, channels and connected systems. Acceptance evidence: questions.test.mjs › BOOKS-AGENT the agent asks the owner what does not add up, by email first; the answer files it and the agent learns the rule only when told (model and mail faked at their network edge; replies through the Worker's email handler).
19. PAN-19
    Stripe payouts and Gusto payroll book themselves With the business's own Stripe key connected, the owner names the bank account payouts land in, the sales income account and the Activity start date. Supported USD charges, refunds, disputes and fees post through Stripe clearing at each balance transaction’s provider creation date (UTC). Invoice-link charges adopt the existing receipt and fee entries rather than posting sales twice. A payout is one clearing-to-bank transfer at its provider event date; its arrival date remains the expected date for bank matching, and its reconciliation view keeps gross sales, invoiced charges, fees and refund totals. This corrects the former payout-arrival recognition timing to standard clearing practice. Every provider item is inventoried for comparison. Previously booked payout journals stay immutable and their constituent IDs are associated before any new recognition; native invoice receipts stay intact. Otherwise-unowned events before Activity start date remain named historical items for human reconciliation, never automatic historical sales or an invented opening adjustment. Supported events from that date post once at provider time; locked or unsupported events stay named with their reason. With the installation's own Gusto app (GUSTO_CLIENT_ID, GUSTO_CLIENT_SECRET), the owner connects the Gusto company by OAuth and names the bank account Gusto debits; each processed regular or off-cycle payroll posts as one balanced entry on its check date (gross wages, employer taxes, company benefits and reimbursements; Gusto's net pay, tax, reimbursement and child-support debits, the tax debit split into taxes withheld from employees and employer taxes; paper checks, deductions and deferred taxes to Payroll liabilities); totals that do not add up wait for a person with the difference. Each booked payout or payroll is matched automatically to the bank line(s) that show it, from a feed or a file (one combined debit or one per kind), with an undo after which it is the person's to match; reading again never books twice. RER Managed hosting has no outbound connection for Stripe or Gusto yet, and says so in one line. See [docs/stripe-and-gusto.md](docs/stripe-and-gusto.md). PROC-001 to PROC-003, PAYROLL-001 and PAYROLL-002 extend it to every processor and payroll provider. Acceptance evidence: connected.test.mjs › PAYOUT-001 a Stripe payout is split into gross sales, Stripe fees and refunds, matched to its bank deposit, and never booked twice; connected.test.mjs › PAYROLL-001 a Gusto payroll posts as one balanced entry (wages, employer taxes, withholdings, net pay) matched to its bank debits, once (Stripe and Gusto faked at their network edge).

View as agent

Everything on this page is in these files, copied unmodified from the release. An agent evaluating Pantry can read them instead of the page.

seed.json

The manifest: capabilities, outside services, extension points, limits, operating cost and deployment needs.

CONTRACT.md

The requirements on this page, in source form.

AGENTS.md

Instructions for the coding agent that maintains an installation.

LICENSE

RELEASE.json

README.md

Source setup, available commands and implementation status.

OPERATIONS.md

How the project is set up, operated and deployed.

ACCEPTANCE.md

What the publisher accepts as a finished release.

Every project, with its availability, is in /agents/catalogue.json; the agents page describes the machine-readable files.