Update to Economico

{
  "description": "Keep an Economico business's books, record customer and vendor agreements, invoices, receipts and payments, and read financial reports.",
  "included_files": [],
  "name": "economico",
  "skill_md_contents": "---\nname: economico\ndescription: Keep an Economico business's books, record customer and vendor agreements, invoices, receipts and payments, and read financial reports.\n---\n\n# Economico in ChatGPT\n\nEconomico keeps one business's double-entry books as an evidenced, append-only history.\nConnect an Economico account and business through OAuth before using its tools. Someone without\na business creates one on the free Solo plan while connecting.\n\n1. Call `businesses` to find the business the user means and its approved permissions.\n   Supply that business slug on each subsequent call.\n2. Read `business_get` and inspect the relevant parties, contracts and records.\n   Use the individual command tools' descriptions and input schemas to choose the operation.\n   Reads are individual tools such as `parties_list`, `subjects_get` and `ledgers_list`;\n   supply their advertised parameters without an `action` selector.\n   Tool names use underscores: `parties_create` executes the `parties.create` command.\n3. Record only facts supported by the user's evidence. Confirm missing amounts, dates,\n   counterparties and accounting choices with the user. Money uses integer minor-unit strings\n   and a named currency. Supply a UTC `effective_at` and a stable `idempotency_key`; retry the\n   same operation with that same key after an uncertain response. Retrieve an existing receipt\n   with `command_receipt` rather than recording the fact twice.\n4. Read back the resulting records. Use the individually exposed report tools, such as\n   `report_income_statement`, `report_balance_sheet` and `report_activity_claims`, to verify\n   the accounting outcome. Each tool advertises its own parameters; do not send `action` or `kind`. Explain what was recorded\n   and what remains unknown, linking any returned document or report URLs.\n\nRecording a payment describes money that moved elsewhere. Distinguish recording financial\nfacts from instructions that trigger external actions; execute those only on the user's authority.\nA `no_change` result is a successful domain no-op. `record_business_incorporation` records\nan incorporation that already occurred; it does not register a company.\n`record_payment_with_fee` records an existing payment and its processing fee.\n`record_account_transfer` records a completed transfer between company accounts. Neither tool\ninitiates a payment or moves funds.\n\nTo add a coworker, the owner can call `members_invite` with their email and access (`reader`,\n`bookkeeper` or `administrator`). Economico emails them a link; they sign in or create an account\nwith that address and accept it themselves, so tell the user nobody has access until then.\n`member_invitations` lists pending invitations and `members_revoke_invitation` withdraws one.\n\nWhen a feature is unavailable under the current entitlement, explain the restriction and offer\nonly the informational pricing URL returned by the tool. An already entitled account can use its\npaid features here. Paid plan purchases are outside this plugin's interface.\n\n## Agreements, invoices and bills\n\nWhen a new invoice or bill lacks its amount, currency, service date or reference, ask for\nthose facts before recording it. An older agreement or bill does not establish a new one.\n\nA priced service uses a right, a contract granting it, then evidenced phases of that same\nobligation. Reuse matching existing records before creating any. Billing opens a receivable or\npayable; delivery and recognition earn revenue or expense; payment is recorded separately.\n\nFor a fixed-price service, adapt this `activities_create` input to the evidenced amount,\ncurrency and classification. This example is a USD 800 consulting service sold to a customer:\n\n```json\n{\n  \"definition\": {\n    \"model\": \"priced-rights-v1\",\n    \"name\": \"Consulting service\",\n    \"terms\": {\n      \"price\": {\"type\": \"integer\", \"unit\": \"USD\", \"default\": \"80000\"},\n      \"currency\": {\"type\": \"text\", \"default\": \"USD\"}\n    },\n    \"facts\": {},\n    \"ledgers\": {\n      \"money\": {\"classification\": \"gaap\", \"unitKind\": \"currency\", \"unitCode\": \"USD\", \"decimals\": 2, \"accountTemplate\": \"gaap_startup\"}\n    },\n    \"price\": {\"treatment\": \"priced\", \"calculation\": {\"type\": \"fixed\", \"amount\": \"term:price\"}, \"currencyTerm\": \"currency\"},\n    \"economics\": {\n      \"kind\": \"service\", \"direction\": \"provide\",\n      \"billing\": {\"timing\": \"arrears\"}, \"recognition\": {\"timing\": \"delivery\"},\n      \"classification\": {\"monetaryLedger\": \"money\", \"revenueCategory\": \"consulting\"}\n    }\n  }\n}\n```\n\nFor a purchased service use `direction: \"receive\"` and the evidenced expense classification\ninstead of `revenueCategory`. Hosting uses `expenseAccount: 5210`; cost of revenue uses\n`expenseFunction: \"cost_of_revenue\"`. Choose timing from the agreement; the example is earned\non delivery and billed in arrears. Price calculations reference declared terms or facts.\n\n1. Create the customer/vendor party if absent (`parties_create`, with a stable `partyId`,\n   `name` and `categories: [\"customer\"]` or `[\"vendor\"]`). Create the service right above and\n   retain its returned `documentId`.\n2. Use `contracts_create` with an inline `definition`:\n   `model: \"priced-rights-v1\"`, a descriptive `name`, `parties: [\"customer\"]`, the same\n   `ledgers` declaration, and\n   `activities: [{\"key\":\"service\",\"activityDocumentId\":\"<returned right documentId>\",\"partyRole\":\"customer\",\"ledgers\":{\"money\":\"money\"}}]`.\n   Alongside the definition supply `parties: {\"customer\":\"<partyId>\"}` and\n   `ledgerBindings: {\"money\":\"<existing matching GAAP ledger id>\"}`. Substitute `vendor`\n   for a purchase. Read the business's ledgers to obtain the actual binding.\n3. Accept the returned draft with `contracts_accept`: `contractId`, its current\n   `expectedDocumentId`, `expectedStatus: \"draft\"`, the evidenced acceptance `effectiveAt`,\n   a stable `sourceFactId`, and\n   `evidence: {\"acceptance\":[{\"kind\":\"other\",\"ref\":\"<agreement evidence ref>\"}]}`.\n4. Use `contracts_record` separately for each evidenced phase: `delivery`, `recognition`,\n   and `billing`. Each supplies `contractId`, `activityKey: \"service\"`, the **same**\n   `obligationKey` (e.g. the invoice reference), a distinct stable `occurrenceKey` and\n   `sourceFactId` per phase, its actual `effectiveAt`, and `facts: {}` for this fixed price.\n   Delivery and recognition use `evidence: {\"service\":[{\"kind\":\"other\",\"ref\":\"<delivery evidence ref>\"}]}`;\n   billing uses `evidence: {\"billing\":[{\"kind\":\"other\",\"ref\":\"<invoice evidence ref>\"}]}`\n   and the evidenced `dueDate` in `YYYY-MM-DD` format. Use the user's evidence refs literally;\n   source fact identifiers name the distinct facts. Record recognition as well as delivery\n   when the service is earned. Read outcomes and `report_activity_claims` to verify the amount,\n   direction, outstanding balance and originating statement.\n\n## Payments and reconciliation\n\nUse `report_activity_claims` to establish whether invoices or bills remain open. An empty\n`subjects_list` filtered by `record_type` alone does not establish the absence of priced-right\nclaims; inspect the relevant contract and its claim report before making that statement.\n\nRead the open claim through `report_activity_claims` and find the matching counterparty,\ncontract, currency and invoice. Retain both its `claimId` and `component`.\nReuse the evidenced financial account, or register it with `accounts_register` using\n`financialAccountId`, `name`, `currency` and `kind` (e.g. `checking`).\nUse `payments_record` with that account, `direction: \"in\"` for a customer receipt or `\"out\"`\nfor a vendor payment, `amount` in minor units, `currency`, `partyId`, `effectiveAt`,\na stable `sourceFactId`, `evidence: [{\"kind\":\"other\",\"ref\":\"<payment evidence ref>\"}]`, and\n`allocations: [{\"claimId\":\"<returned claimId>\",\"component\":\"<returned component>\",\"amount\":\"<allocated minor units>\"}]`.\nRead back the payment and claim to prove partial or full settlement. This records a transfer\nthat already happened; it does not initiate one.\n\nFor reconciliation run the available income statement, balance sheet and claim reports using\nthe requested period and cutoff. Verify cash using payment/collections reports and cash ledger\npostings. Separate unrelated opening or platform entries. Explain\nprofit from earned revenue less recognized expenses, and cash from actual receipts/payments;\nunpaid invoices and bills explain the difference. Read report parameter schemas for cutoff\nsemantics and show the remaining receivable/payable rather than treating them as cash.\n"
}