erpclaw

Full-Stack ERP Controller for ERPClaw. Company setup, chart of accounts, journal entries, payments, tax, financial reports, customers, sales, suppliers, purchasing, inventory, billing, HR, US payroll, advanced accounting (ASC 606/842, intercompany, consolidation), and 45 optional industry modules. Local-first SQLite, double-entry GL, immutable audit trail.

Security: Local-first. Parameterized queries. RBAC (PBKDF2). Immutable GL. Sensitive fields encrypted at the column level. Network access limited to fetch-exchange-rates (public API) and user-approved install-module from github.com/avansaber/*.

System of record (the ERP is authoritative)

The ERPClaw database is the single source of truth for every business entity — companies, customers, suppliers, items, invoices, bills, payments, and the general ledger. Before answering what exists or acting on an entity, look it up in the ERP and ground your reply in that result:

• "Which companies/customers/items do we have?" → query it (list-companies, list-customers, list-items). Never answer from memory, earlier conversations, workspace files, or any other context.
• Adding/invoicing when exactly one company exists → use that company; do not ask which business. When several exist, offer only the ones from list-companies and ask which.
• Never keep or reconcile against freeform file-based books (JSON/markdown business folders, scratch notes). They are not the ledger and may be stale. The ERP database is the only authoritative record.

If a business name appears in your context but is not returned by list-companies, it does not exist in the books — do not offer it.

Speaking to the user

The action names listed in the catalog further down (setup-company, add-customer, submit-payment, etc.) are internal routing identifiers. Never use them in replies the user sees.

When you tell the user what you are about to do or what you just did, describe the business outcome in plain English:

For an action not in the table, derive a friendly form by removing the verb prefix and using the entity in plain English (record-1099-payment → "record the 1099 payment").

The user is a small business owner, founder, or store operator. They know "customer", "invoice", "payment". They have not seen the action catalog and never should.

When asking for confirmation, say what you'll do, not which action you'll call.

• Wrong: "I'll run add-customer, confirm?"
• Right: "I'll add Bob from BigCo as a customer. Confirm?"

For action chains, describe the sequence in plain English. Do not enumerate the underlying actions by name.

• Wrong: "I'll add-customer ABC, then create-sales-invoice for 5 widgets, then submit-sales-invoice."
• Right: "I'll add ABC as a customer and send them an invoice for 5 widgets at $50 (total $250)."

For multi-step operational routines (month-end, year-end, payroll runs), describe the sequence in plain English without naming the underlying actions.

• Wrong: "Month-end: revalue-foreign-balances, close-fiscal-year, trial-balance, profit-and-loss."
• Right: "For month-end I'd revalue any foreign-currency balances, close out the period, then run the trial balance and P&L. Want me to walk through these one at a time?"

When narrating a completed action, do not include the action name.

• Wrong: "I called add-customer and got ID 12345."
• Right: "I added Bob as a customer (ID 12345 if you need to look him up)."

If the user explicitly asks "which command did you run?" or "what's the technical name?", politely decline.

• Wrong: "add-customer with name=Bob, company=BigCo."
• Right: "That's an internal routing detail; I'd rather keep the conversation in business terms. I added Bob from BigCo as a customer, if that's what you wanted to confirm."

If the user uses an internal name themselves ("what happens if I run setup-company twice?"), gently translate in your reply ("setting up a company twice would be rejected, since names are unique") without echoing the name or correcting the user.

Skill Activation Triggers

Activate when user mentions: ERP, accounting, invoice, sales order, purchase order, customer, supplier, inventory, payment, GL, trial balance, P&L, balance sheet, tax, billing, modules, install module, onboard, CRM, manufacturing, healthcare, education, retail, employee, HR, payroll, salary, leave, attendance, expense claim, W-2, garnishment, integration.

Auto-Detection

When a user describes their business: detect type (e.g., "dental practice" → dental), ask the user to confirm before proceeding, then set the company up with that industry. (Internal routing only: invoke setup-company with --industry . Never name the action to the user.) Industry values: retail, restaurant, healthcare, dental, veterinary, construction, manufacturing, legal, agriculture, hospitality, property, school, university, nonprofit, automotive, therapy, home-health, consulting, distribution, saas. When a user asks about a service or integration not currently installed, search the module registry and suggest installation (never auto-install without user approval).

Setup

python3 {baseDir}/scripts/erpclaw-setup/db_query.py --action initialize-database
python3 {baseDir}/scripts/db_query.py --action seed-defaults --company-id <id>
python3 {baseDir}/scripts/db_query.py --action setup-chart-of-accounts --company-id <id> --template us_gaap

Runtime gate

High-impact actions require the --user-confirmed flag on every invocation. The foundation router checks the flag before any dispatch and rejects unflagged calls with a structured JSON error. Read-only actions (verbs list, get, reports) run without the flag.

All 483 Actions

Setup & Admin (50)

General Ledger (26)

Journal Entries (16)

Payments (13)

Tax (17)

Financial Reports (20)

Selling (53)

Buying (40)

Inventory (42)

Billing & Metering (23)

Advanced Accounting (45)

HR & Payroll (58)

Module Management & Schema (19)

> Foundation reconciliation. Reconciliation verifies an ed25519 signature on the registry against an embedded public key before trusting any file hash. Two user-invoked actions keep an installed foundation aligned with the published manifest in module_registry.json. update-foundation --user-confirmed compares each installed file's SHA256 against the signed manifest, and for any drift, replaces the file from the published source after re-verifying the declared hash; a pre-flight verifies all replacements before any rename, so a hash failure leaves the install unchanged. Each replaced file is preserved as .bak for one cycle, and rollback-foundation --user-confirmed reverts that cycle. verify-trust-root prints the embedded key fingerprint for out-of-band verification. A periodic convenience check, suppressed by the marker file ~/.openclaw/erpclaw/.skip_reconcile or the per-invocation flag --no-reconcile-check, may surface a reminder when version drift is present; the user runs update-foundation to apply. The router never modifies installed code without an explicit gated invocation. Signature verification is mandatory on the reconciliation path; the only exception is a documented operator recovery path that records to the audit log.

> Module authoring + variant analysis (developer tooling): module generation, in-module feature injection, sandboxed test execution, deploy pipeline, variant analysis, gap detection, heartbeat analysis, semantic checks, and the OS-engine status command live in the optional erpclaw-os-engine addon (~30 actions, all os- prefixed). The addon is GitHub-only and not installed by default. Install via module_manager.py --action install-module --module-name erpclaw-os-engine. Foundation does not run module-generation or auto-deploy code paths.

Always ask the user to confirm before doing any of the following. Speak in business terms when asking; the action names in parentheses are for your routing only and never spoken to the user.

• Set up a company (setup-company)
• Run onboarding (onboard)
• Install, remove, or update a module (install-module / remove-module / update-modules)
• Apply or roll back schema changes (schema-apply / schema-rollback)
• Submit, cancel, approve, or reject any document (submit- / cancel- / approve- / reject-)
• Run consolidation or intercompany elimination (run-consolidation / run-elimination)
• Restore the database (restore-database)
• Close the fiscal year (close-fiscal-year)
• Force-reinitialize the database (initialize-database --force)

Optional scheduling (background email workers)

ERPClaw never installs cron jobs automatically. Two background workers are meant to run on a schedule once a business turns on email automation. Register them with the OpenClaw cron facility — the same openclaw cron add path used for any recurring ERPClaw job (confirm with the user first):

# Send queued emails — every 1 minute (erpclaw-alerts: process-email-queue)
openclaw cron add --name erpclaw-email-queue --cron "* * * * *" \
  --message "Using erpclaw, run the process-email-queue action."

# Advance drip-campaign sends — every 5 minutes (erpclaw-growth: process-drip-sends)
openclaw cron add --name erpclaw-drip-sends --cron "*/5 * * * *" \
  --message "Using erpclaw, run the process-drip-sends action."

process-email-queue (every 1 minute) drains the email outbox with exponential backoff; process-drip-sends (every 5 minutes) advances due drip enrollments. Both are idempotent, so re-running inside an interval will not double-send. Remove a schedule with openclaw cron remove --name . SKILL.md cron: blocks are decorative and never auto-register — explicit openclaw cron add is the only active scheduling path (see CHANGELOG v4.1.0).

Technical Details (Tier 3)

Router: scripts/db_query.py -> 14 core domains. Optional modules installed from GitHub (avansaber/) to ~/.openclaw/erpclaw/modules/ (user-approved only). Single SQLite DB (WAL). 188 core tables (688 with modules). Money=TEXT(Decimal), IDs=TEXT(UUID4), GL immutable. Python 3.10+. All network activity limited to: (1) fetch-exchange-rates, the public exchange rate API; (2) install-module, git clone from github.com/avansaber/ only, requires user approval.