Vendor-agnostic read-only daily money cockpit for a small business on QuickBooks or Xero. Binds the accounting connection through canonical core.acct.* op-steps (invoice / payment / customer search), so the same recipe runs against whichever accounting vendor you connected (the resolver dispatches each op to the bound vendor and projects its raw records to the canonical accounting fields). It surfaces open invoice pressure, what is actually overdue by due date, recent cash-in, and customers missing an email - without creating, voiding, or paying anything. Canonical accounting op-steps are read-only; every money write stays approval-gated in the accounting capability pack.
Accounting (any vendor)
The vendor-neutral accounting pack — two cross-vendor money-ops recipes that run against whatever accounting platform you enroll (QuickBooks Online or Xero, or any registered accounting vendor). Every read uses a `core.acct.<entity>.search` kernel op (invoice / payment / customer), so the pack carries no bundled catalog: each op resolves at run against the catalog the bound connection's vendor declares, and projects the canonical accounting fields (balance / due_date / customer_id / email) — never raw vendor records. This is the showcase for the `core.acct.*` canonical convention; the catalog + the money-write surface (invoice/payment/refund creates, always approval-gated) live in the per-vendor capability packs (`accounting-quickbooks` / `accounting-xero`), which you also install to bind a connection. Canonical accounting op-steps are read-only — `overdue-invoice-chase` only sends a reminder email through the gated mail-send kernel ingredient, never moving money. Installs dormant until you pick an enrolled accounting connection for each recipe's `acct` variable (Settings -> the recipe), then runs against the D-165 gateway (operation-level risk / grant / approval + per-call audit).
What this pack installs
Included recipes
2 pinned recipes
This pack installs the complete recipe workflow together.
Vendor-agnostic action workflow over an accounting capability pack (QuickBooks or Xero) and the mail outbox. Binds the accounting connection through canonical core.acct.* op-steps (invoice / customer search), so the same recipe runs against whichever accounting vendor you connected: the resolver dispatches each op to the bound vendor and projects its raw records to the canonical accounting fields (balance / due_date / customer_id / email). It finds invoices that are open and past due, resolves which customers are overdue and have an email on file, drafts one concise reminder per customer, and sends the approved batch through the mail-send kernel ingredient. The chase emails the customer about their outstanding balance; it never creates, voids, or pays anything (canonical accounting op-steps are read-only — money writes ride the explicit gated ingredient binding). Because mail-send is the irreversible send-class boundary, attended runs hold the send step at the preflight approval gate.
Trust & control
What installing this whole pack would let it do. Recued grants these permissions at install — review them there before approving.