jaz-clio 5.74.2 → 6.0.1

package/assets/skills/jobs/references/fa-review.md

@@ -1,8 +1,8 @@
 # Fixed Asset Review
 
-> Annual housekeeping of the FA register. Identify assets requiring disposal/write-off, reconcile register to TB, verify Jaz auto-depreciation matches schedules. Walk the steps below in order, calling the named platform tools directly. (Local CLI convenience: `clio jobs fa-review` prints this same phased checklist.)
+> Annual housekeeping of the FA register. Identify assets requiring disposal/write-off, reconcile register to TB, verify Jaz auto-depreciation matches schedules. Walk the steps below in order, calling the named platform tools directly.
 
-## Tools, recipes, calculators this job uses
+## Tools and calculators this job uses
 
 ### Platform tools
 - **`search_fixed_assets(filter: {status: {in: ['ACTIVE', 'DISPOSED', 'DISCARDED']}}, limit: 200)`**, step 1: enumerate FAs. Paginate.
@@ -11,24 +11,24 @@
 - **`generate_fa_recon_summary(primarySnapshotStartDate: <year-start>, primarySnapshotEndDate: <year-end>)`**, step 3: reconcile movement (opening + additions − disposals − depreciation = closing).
 - **`generate_general_ledger(accountResourceIds: [<FA category GL>], startDate, endDate)`**, step 4: per-FA-category GL movement vs FA register.
 - **`mark_fixed_asset_sold(resourceId: <id>, depreciationEndDate, assetDisposalGainLossAccountResourceId, saleBusinessTransactionType, saleItemResourceId)` / `discard_fixed_asset(resourceId: <id>, disposalDate, depreciationEndDate)`**, step 5: status updates for disposals. Mirror endpoints `POST /api/v1/mark-as-sold/fixed-assets` (sale) / `POST /api/v1/discard-fixed-assets/{id}` (scrap).
-- **`plan_recipe(recipe: 'asset-disposal', ...)` + `execute_recipe(...)`**, step 5: invoke per disposal identified during review (see the `asset-disposal` recipe).
-- **`bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`**, step 5 / 6: finalize disposal journals + any pending DDB / 150DB depreciation DRAFTs from the `depreciation` recipe.
+- **`calculate(type: 'asset-disposal', ...)`**, then `create_capsule` + `create_journal` with `capsuleResourceId`, step 5: per disposal identified during review (see the `asset-disposal` recipe).
+- **`bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`**, step 5 / 6: finalize disposal journals + any pending DDB / 150DB depreciation DRAFTs posted from a `depreciation` schedule.
 
 ### Calculators (cross-check, no API key needed)
 - **`clio calc depreciation --cost --salvage --life --method --frequency annual --json`**: step 4 per-asset cross-check.
-- **`clio calc asset-disposal`**: step 5 per-disposal cross-check (auto-invoked by recipe).
+- **`clio calc asset-disposal`**: step 5 per-disposal gain/loss (the CLI form of `calculate(type: 'asset-disposal', ...)`).
 
 ### Cross-references
 - Run as part of year-end; the FA review feeds audit-prep + Form C-S capital allowances.
 - Sibling jobs: `audit-prep.md` step 8 (auditor reviews FA register + recon summary), `month-end-close.md` step 9 (monthly depreciation; this job is the periodic comprehensive review).
-- Recipes: `asset-disposal`, `depreciation` (DDB / 150DB engine). See the transaction-recipes skill.
+- Calculator types used: `asset-disposal`, `depreciation` (DDB / 150DB). See the transaction-recipes skill for the pattern.
 - API rules: `jaz-api/SKILL.md` rules 91-92c (fixed-asset endpoints).
 
 ---
 
 ## Steps
 
-Walk steps 1-8 below. (Local CLI: `clio jobs fa-review` prints the same phased checklist.)
+Walk steps 1-8 below.
 
 ## Step 1: Enumerate FAs
 
@@ -45,7 +45,7 @@ For each ACTIVE asset, flag for practitioner attention:
 - **Recently acquired without `effectiveLife`**: depreciation can't run; halt and surface.
 - **Pre-flagged by the user as a disposal candidate**: act on it.
 - **Damaged / no longer in use** (per practitioner inspection): write off.
-- **Mid-life disposals** (sold or traded in during the period): per asset-disposal recipe.
+- **Mid-life disposals** (sold or traded in during the period): per step 5.
 
 ## Step 3: FA register reconciliation
 
@@ -58,7 +58,7 @@ Keep both the FA summary and the recon summary. Assert per FA category:
 - `closingNbv == openingNbv + additions - disposals - depreciation` (the recon formula).
 - Sum of per-asset NBV in the register equals TB `<FA cost> - <Accumulated Depreciation>` line for that category.
 
-If mismatch beyond the materiality threshold: investigate via `generate_general_ledger(accountResourceIds: [<FA category cost GL>], startDate, endDate)`. Common: a disposal posted via the `asset-disposal` recipe but the step 5 `mark_fixed_asset_sold` / `discard_fixed_asset` was missed; Jaz continues auto-depreciating.
+If mismatch beyond the materiality threshold: investigate via `generate_general_ledger(accountResourceIds: [<FA category cost GL>], startDate, endDate)`. Common: a disposal journal was posted but the step 5 `mark_fixed_asset_sold` / `discard_fixed_asset` was missed; Jaz continues auto-depreciating.
 
 ## Step 4: Depreciation cross-check
 
@@ -67,8 +67,8 @@ For each ACTIVE SL asset (Jaz auto-depreciates):
 - Compare to actual `generate_general_ledger(accountResourceIds: [<Depreciation Expense for this category>], startDate: <year-start>, endDate: <year-end>)` movement.
 - Should match within rounding ($0.12 tolerance for full-year SL).
 
-For each ACTIVE DDB / 150DB asset (recipe-managed, see the `depreciation` recipe):
-- Per capsule: the 12 monthly DRAFT depreciation journals should already be FINALIZED via the monthly close. This cannot be verified with a filter: journals carry no capsule or fixed-asset link in either direction (measured 2026-09-07), so report the capsule and its `totalTransactions` count for the practitioner to check, rather than searching by date.
+For each ACTIVE DDB / 150DB asset (depreciated by journals you post from a `depreciation` schedule, see the `depreciation` recipe):
+- Per capsule: the 12 monthly DRAFT depreciation journals should already be FINALIZED via the monthly close. This cannot be verified with a filter: journals cannot be searched by capsule or fixed asset (measured 2026-09-07; `get_journal` on one journal does return its `capsule`), so report the capsule and its `totalTransactions` count for the practitioner to check, rather than searching by date.
 - If the practitioner identifies remaining DRAFTs, finalize those specific resourceIds with `bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`, never a set collected by an unscoped search.
 
 Cross-check via `clio calc depreciation --frequency annual --json` per asset; auditor will sample-test.
@@ -78,31 +78,30 @@ Cross-check via `clio calc depreciation --frequency annual --json` per asset; au
 For each disposal identified in step 2:
 
 ```
-plan_recipe(
-  // Accounts, capsule and counterparty are not plan_recipe params: execute_recipe resolves accounts from the CoA and takes bankAccountName / contactName.
-  recipe: 'asset-disposal',
-  cost, salvageValue, usefulLifeYears, acquisitionDate, disposalDate, proceeds, method,
-  ...
-)
-execute_recipe(...)
-update_journal(resourceId: <disposal journal id>, saveAsDraft: false)
+calculate(type: 'asset-disposal', cost, salvageValue, usefulLifeYears, acquisitionDate, disposalDate, proceeds, method)
 ```
 
-Then the manual FA-register status update (engine-skipped; see the `asset-disposal` recipe):
+The calculator returns the accumulated depreciation, net book value and gain or loss; it posts nothing. These assets are in the register, and the register books a disposal itself, so do NOT also post the calculator's full disposal journal (that books the disposal twice). Use its figures as the cross-check.
+
 ```
-mark_fixed_asset_sold(resourceId: <asset id>, depreciationEndDate, assetDisposalGainLossAccountResourceId, saleBusinessTransactionType, saleItemResourceId)
-// or, for a write-off with no sale:
+// Sale: post the proceeds as the sale entry (the credit line must be on the asset's fixed-asset account), then mark sold against that line
+create_capsule(capsuleTypeResourceId: <Asset Disposal type id, from list_capsule_types>, title: <blueprint.capsuleName>)
+create_journal(valueDate: <disposalDate>, autoReference: true, journalEntries: [Dr <bank> proceeds, Cr <asset account> proceeds], saveAsDraft: false, capsuleResourceId: <capsule id>)
+mark_fixed_asset_sold(resourceId: <asset id>, depreciationEndDate, assetDisposalGainLossAccountResourceId, saleBusinessTransactionType: 'JOURNAL_MANUAL', saleItemResourceId: <the journal's credit line id>)
+// Write-off with no sale: no journal
 discard_fixed_asset(resourceId: <asset id>, disposalDate, depreciationEndDate)
 ```
 
+Full walk-through, including an asset that is not in the register: the `asset-disposal` recipe.
+
 For scrap / write-off (no proceeds): `discard_fixed_asset(...)`; its own description is "Discard (write off) a fixed asset". There is no `WRITTEN_OFF` status; the declared set is ACTIVE, ONGOING, COMPLETED, DRAFT, DISPOSED, SOLD, DISCARDED, CLOSED_OUT.
 
 ## Step 6: Write-off of fully depreciated unused assets
 
 For assets at salvage value AND no longer in use:
 - If salvage value > 0 and asset is to be retained at salvage: leave ACTIVE; no further depreciation.
-- If salvage value > 0 and asset is to be scrapped: invoke the `asset-disposal` recipe with `proceeds: 0` → loss = salvage value.
-- If salvage value = 0 and asset is to be scrapped: minimal P&L impact; the `asset-disposal` recipe is still required to clear the cost + accumulated depreciation balances against each other.
+- If salvage value > 0 and asset is to be scrapped: run step 5 with `proceeds: 0` → loss = salvage value.
+- If salvage value = 0 and asset is to be scrapped: minimal P&L impact; the step 5 disposal journal is still required to clear the cost + accumulated depreciation balances against each other.
 
 ## Step 7: Per-category GL reconciliation
 
@@ -130,11 +129,11 @@ These feed `audit-prep.md` step 8 supporting schedules.
 | Source | Error | Recovery |
 |--------|-------|----------|
 | Step 1 | `search_fixed_assets` returns more than the page limit | Paginate via `offset`. Most SMBs have <100 FAs. |
-| Step 3 | Recon doesn't tie | Disposed asset still ACTIVE in register (the `asset-disposal` recipe leaves the FA-register status update to you). Audit each disposal's status. |
+| Step 3 | Recon doesn't tie | Disposed asset still ACTIVE in register (posting the disposal journal does not update the FA register; that is a separate call). Audit each disposal's status. |
 | Step 4 | DDB / 150DB DRAFTs unfinalized | Likely a missed monthly close. Finalize the current ones and surface to the user; the auditor will otherwise see 12 months' depreciation in one period. |
 | Step 4 | SL depreciation off by > $0.12 | A monthly depreciation period was skipped (asset created mid-month with mis-aligned `depreciationStartDate`). Reconcile per asset. |
-| Step 5 | `update_fixed_asset` to DISPOSED | 422 `pending_depreciation_journals` | DRAFT depreciation journals exist for periods after disposal date. **Do not select these with a filter**: journals cannot be narrowed to one fixed asset (`JournalFilter` has no `fixedAssetResourceId`, and a journal row carries no asset link), so a date+status search returns every DRAFT in the org and `delete_journal` over it would destroy unrelated work. Surface the asset and the blocking periods to the practitioner and let them identify the journals, then retry. |
-| Step 6 | Trying to dispose an FA at NBV = 0 with no proceeds | Recipe still works but creates a no-effect journal. May be skippable; surface to practitioner. |
+| Step 5 (`mark_fixed_asset_sold` / `discard_fixed_asset`) | 422 `pending_depreciation_journals` | DRAFT depreciation journals exist for periods after disposal date. **Do not select these with a filter**: journals cannot be narrowed to one fixed asset (`JournalFilter` has no `fixedAssetResourceId`, and a journal row carries no asset link), so a date+status search returns every DRAFT in the org and `delete_journal` over it would destroy unrelated work. Surface the asset and the blocking periods to the practitioner and let them identify the journals, then retry. |
+| Step 6 | Trying to dispose an FA at NBV = 0 with no proceeds | The calculator still works but the journal only clears cost against accumulated depreciation, with no P&L effect. May be skippable; surface to practitioner. |
 
 ---
 
@@ -143,5 +142,5 @@ These feed `audit-prep.md` step 8 supporting schedules.
 - `year-end-close.md`: runs this job for the year-end FA review; ask the user for any pre-flagged disposal candidates.
 - `audit-prep.md` step 8: consumes the snapshot files for the audit pack.
 - SG Form C-S statutory filing (see the SG Form C-S section in `SKILL.md`): capital allowances computation reads from the FA register; this job's reconciliation must be clean before the tax computation.
-- `month-end-close.md` step 9: monthly depreciation (Jaz auto-SL + recipe-DDB); this job is the periodic comprehensive register review (typically annual).
-- Recipes: `asset-disposal` (per-disposal), `depreciation` (per-DDB-asset engine).
+- `month-end-close.md` step 9: monthly depreciation (Jaz auto-SL + DDB journals from the `depreciation` calculator); this job is the periodic comprehensive register review (typically annual).
+- Calculator types: `asset-disposal` (per-disposal), `depreciation` (per-DDB-asset).

package/assets/skills/jobs/references/gst-vat-filing.md

@@ -1,8 +1,8 @@
 # GST/VAT Filing
 
-> Produce the filing-ready summary + supporting detail for IRAS F5 (SG) or BIR Form 2550Q (PH). Does NOT file; produces the numbers + supporting detail. Walk the steps below in order, calling the named platform tools directly. (Local CLI convenience: `clio jobs gst-vat --period <YYYY-QN>` prints this same phased checklist.)
+> Produce the filing-ready summary + supporting detail for IRAS F5 (SG) or BIR Form 2550Q (PH). Does NOT file; produces the numbers + supporting detail. Walk the steps below in order, calling the named platform tools directly.
 
-## Tools, recipes, calculators this job uses
+## Tools and calculators this job uses
 
 ### Platform tools
 - **`generate_vat_ledger(startDate: <period-start>, endDate: <period-end>)`**, step 1: the canonical tax ledger. Returns input + output tax totals + per-tax-profile breakdown.
@@ -23,7 +23,7 @@
 
 ## Steps
 
-Walk steps 1-8 below. (Local CLI: `clio jobs gst-vat --period 2025-Q1` prints the same phased checklist.)
+Walk steps 1-8 below.
 
 ## Step 1: Pull the tax ledger
 

package/assets/skills/jobs/references/month-end-close.md

@@ -1,8 +1,8 @@
 # Month-End Close
 
-> The foundational close cadence: every quarter-end and year-end builds on it. For an SMB, 1-3 days depending on transaction volume. Walk the phases below in order, calling the named platform tools directly. (Local CLI convenience: `clio jobs month-end --period <YYYY-MM>` prints this same phased checklist.)
+> The foundational close cadence: every quarter-end and year-end builds on it. For an SMB, 1-3 days depending on transaction volume. Walk the phases below in order, calling the named platform tools directly.
 
-## Tools, recipes, calculators this job uses
+## Tools and calculators this job uses
 
 ### Platform tools: pre-close gates
 - **`search_invoices(filter: {valueDate: {between: [<period-start>, <period-end>]}}, sortBy: 'valueDate', sortOrder: 'ASC', limit: 200)`**: step 1: confirm sales invoices entered. Paginate via `offset`.
@@ -11,13 +11,15 @@
 - **`generate_aged_ar(endDate: <date>)` / `generate_aged_ap(endDate: <date>)`**: steps 4-5: aging reports tied to TB AR / AP balances.
 
 ### Platform tools: accruals + valuations
-- **`plan_recipe(recipe: 'accrued-expense', ...)` / `execute_recipe(...)`**: step 6: per recurring accrual whose last posting predates the period end.
-- **`plan_recipe(recipe: 'prepaid-expense', ...)`**: step 7: only for new prepaid setup; ongoing recognition runs from the scheduler created at setup.
-- **`plan_recipe(recipe: 'deferred-revenue', ...)`**: step 8: same setup-vs-recognition note as prepaid.
-- **`plan_recipe(recipe: 'depreciation', ...)`**: step 9: only when an asset uses non-SL method (DDB, 150DB). Jaz native FA handles SL automatically. Verify FA register first.
-- **`plan_recipe(recipe: 'leave-accrual', ...)` / `execute_recipe(...)`**: step 10: monthly leave accrual; the engine creates the scheduler so it auto-fires next month.
-- **FX revaluation**: step 12: **Jaz auto-handles**. The recipe is verification-only via `clio calc fx-reval`; do NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` (would double-post).
-- **`plan_recipe(recipe: 'ecl', ...)`**: step 13: top-up bad-debt provision based on `generate_aged_ar` buckets.
+Every calculated step below is the three-step flow in `building-blocks.md` § Calculated schedules: `calculate` (schedule + journal lines, posts nothing), then `list_capsule_types` + `create_capsule`, then one `create_journal` / `create_bill` / `create_invoice` / `create_cash_in` / `create_cash_out` per step with `capsuleResourceId`.
+
+- **`calculate(type: 'accrued-expense', ...)`**: step 6: per recurring accrual whose last posting predates the period end.
+- **`calculate(type: 'prepaid-expense', ...)`**: step 7: only for new prepaid setup; ongoing recognition finalizes the journals posted at setup.
+- **`calculate(type: 'deferred-revenue', ...)`**: step 8: same setup-vs-recognition note as prepaid.
+- **`calculate(type: 'depreciation', ...)`**: step 9: only when an asset uses non-SL method (DDB, 150DB). Jaz native FA handles SL automatically. Verify FA register first.
+- **`calculate(type: 'leave-accrual', ...)`**: step 10: monthly leave accrual; the same amount repeats, so one `create_scheduled_journal` covers the year.
+- **FX revaluation**: step 12: **Jaz auto-handles**. `calculate(type: 'fx-reval', ...)` is verification only; do NOT post its result (would double-post).
+- **`calculate(type: 'ecl', ...)`**: step 13: top-up bad-debt provision based on `generate_aged_ar` buckets.
 
 ### Platform tools: reconciliation execution
 - **`view_auto_reconciliation(bankStatementEntryResourceIds: [<id>, ...])`**: step 3: READ-ONLY suggestions (does NOT write). Per-entry only; source ids from `search_bank_records` (status `UNRECONCILED`).
@@ -32,7 +34,7 @@
 - **`bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`**: step 17: clear residual drafts before lock.
 - **`update_account(resourceId: <CoA root>, lockDate: <period-end>)`**: step 18: lock the period.
 
-### Calculators (cross-check, no API key needed)
+### Calculators on the local CLI (same engine as `calculate`, no API key needed)
 - **`clio calc accrued-expense`**: step 6: independently compute accrual amount.
 - **`clio calc prepaid-expense`** / **`clio calc deferred-revenue`**: steps 7-8: setup events only.
 - **`clio calc depreciation`**: step 9: FA register cross-check.
@@ -42,14 +44,14 @@
 ### Cross-references
 - Org inputs this job needs (confirm with the user when not already on file): the list of recurring accruals, the bank accounts, the materiality threshold, the CoA mapping, the base currency, and whether the org is multi-currency.
 - Sibling jobs: `bank-recon.md` (step 3 detail), `payment-run.md` (typically run separately mid-month), `quarter-end-close.md` / `year-end-close.md` (additive on top of this base).
-- Recipes invoked: `accrued-expense`, `prepaid-expense`, `deferred-revenue`, `depreciation`, `leave-accrual` + `accrued-expense` (employee accruals / bonus), `loan` (verification only; engine emits interest), `fx-reval`, `ecl`. See the transaction-recipes skill for engine entry points.
+- Calculator types used: `accrued-expense`, `prepaid-expense`, `deferred-revenue`, `depreciation`, `leave-accrual` + `accrued-expense` (employee accruals / bonus), `loan`, `fx-reval` (verification only), `ecl`. See the transaction-recipes skill for the accounting pattern behind each.
 - API rules: `jaz-api/SKILL.md` rules 2 (valueDate not issueDate), 14 (saveAsDraft default), 18 (bank-accounts envelope), 31 (currency object shape), 36 (endDate for AR/AP point-in-time), 125 (recon NOT idempotent).
 
 ---
 
 ## Phase sequence
 
-This playbook runs 5 phases for the period: pre-close gates → accruals & adjustments → valuations → verification → lock. Walk them in order, calling the platform tools named in each step. (A local CLI run of `clio jobs month-end --period 2025-01 --currency <base>` prints the same phased checklist.)
+This playbook runs 5 phases for the period: pre-close gates → accruals & adjustments → valuations → verification → lock. Walk them in order, calling the platform tools named in each step.
 
 ## Phase 1: Pre-close gates
 
@@ -67,7 +69,7 @@ Compare count + sum against POS / sales register. Missing invoices = understated
 search_bills(filter: {valueDate: {between: ['2025-01-01', '2025-01-31']}}, sortBy: 'valueDate', sortOrder: 'ASC', limit: 200)
 ```
 
-Cross-reference against email + supplier portals + physical mail. Late bills = missed expenses = overstated profit. For PDFs in hand: invoke `mcp magic create --file <pdf>` (Jaz Magic OCR + autofill) to generate the bill draft.
+Cross-reference against email + supplier portals + physical mail. Late bills = missed expenses = overstated profit. For PDFs in hand: `create_bt_from_attachment` with the file and `businessTransactionType: 'BILL'` (Jaz Magic OCR + autofill; local CLI: `clio magic create --file <pdf> --type bill`) to generate the bill draft.
 
 ### Step 3: Bank reconciliation
 
@@ -98,61 +100,61 @@ For each recurring accrual the org runs whose last posting predates `2025-01-31`
 
 1. Compute amount per the accrual's estimation method (`prior_month` via `search_journals`, `trailing_3m_avg`, `budget`, `fixed_amount`).
 2. Cross-check: `clio calc accrued-expense --amount <computed> --periods 1 --json`.
-3. `plan_recipe(recipe: 'accrued-expense', amount: <computed>, periods: 1, startDate: '2025-01-31')` (the engine dates the reversal itself; the accrual accounts resolve from the CoA and the vendor goes to `execute_recipe` as `contactName`).
-4. Resolve `requiredAccounts` + `needsContact` (search/create as needed).
-5. `execute_recipe(...)`. Engine emits dual-entry accrual + reversal scheduler.
+3. `calculate(type: 'accrued-expense', amount: <computed>, periods: 1, startDate: '2025-01-31')` returns the accrual step and its dated reversal step, each with journal lines.
+4. Resolve each line's account to the org's own (`search_accounts`; create if missing and the user agrees).
+5. `list_capsule_types` + `create_capsule` (type `Accrued Expenses`), then one `create_journal(valueDate: <step date>, autoReference: true, journalEntries: [<step lines>], capsuleResourceId: <capsule id>)` per step: the accrual and its reversal.
 6. `validate_journal_draft(resourceId: <id>)` for each draft journal.
 7. After all accruals processed: `bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`.
 
 Cross-check: `generate_trial_balance(endDate: '2025-01-31')`. Sum credit movements against accrual liability accounts. Verify `|sum - expected| ≤ materiality threshold`.
 
-### Step 7: Prepaid expense recognition (finalize this period's pre-emitted journal)
+### Step 7: Prepaid expense recognition (finalize this period's draft journal)
 
 For each existing `Prepaid Expenses` capsule (via `search_capsules(filter: {status: {eq: 'ACTIVE'}})` (capsule type is not filterable; see `building-blocks.md` § Filter limits)):
 
 1. **STOP: do not select these with a filter.** Journals cannot be narrowed to one capsule by a filter: `JournalFilter` declares no `capsuleResourceId`, and `GET /capsules/{id}` returns only `totalTransactions`, a count (measured 2026-09-07). A date+status search returns EVERY matching DRAFT in the org, including drafts a practitioner deliberately parked, so passing it to `bulk_update_journals(items: [{resourceId, saveAsDraft: false}])` finalizes unrelated work. `get_journal` (`GET /journals/{id}`) does return the link as `capsule: {resourceId, type, title}` (measured 2026-09-23), so check each candidate journal's `capsule.resourceId` against this capsule, keep only the matches, and confirm the count with the practitioner before finalizing.
-2. If empty: either the recipe was set up wrong (no journal for this period; investigate via `search_journals` without status filter to see if it's already ACTIVE, then skip), OR the practitioner went off-recipe. Surface to practitioner.
+2. If empty: either the schedule was set up wrong (no journal for this period; investigate via `search_journals` without status filter to see if it's already ACTIVE, then skip), OR the practitioner posted it another way. Surface to practitioner.
 3. If found: collect resourceIds, then `bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`.
-4. New prepaid setups during this period (a new prepaid started this month): invoke `plan_recipe(recipe: 'prepaid-expense', ...)` (see the `prepaid-expense` recipe in the transaction-recipes skill); this creates the bill + N future-dated DRAFT journals; the current period's journal joins the `bulk_update_journals` set above (`bulk_finalize_drafts` takes invoices, bills and credit notes only, never journals).
+4. New prepaid setups during this period (a new prepaid started this month): `calculate(type: 'prepaid-expense', amount, periods, startDate)` (see the `prepaid-expense` recipe in the transaction-recipes skill), `create_capsule` (type `Prepaid Expenses`), then post the blueprint's steps with `capsuleResourceId`: the bill via `create_bill` and the N recognition journals via `create_journal` as future-dated DRAFTs; the current period's journal joins the `bulk_update_journals` set above (`bulk_finalize_drafts` takes invoices, bills and credit notes only, never journals).
 
 ### Step 8: Deferred revenue recognition
 
-Mirror of step 7. Existing `Deferred Revenue` capsules: find this period's DRAFT journal in each, then `bulk_update_journals(items: [{resourceId, saveAsDraft: false}])`. New deferred setups: `plan_recipe(recipe: 'deferred-revenue', ...)` then finalize the current period's journal in the same `bulk_update_journals` call.
+Mirror of step 7. Existing `Deferred Revenue` capsules: find this period's DRAFT journal in each, then `bulk_update_journals(items: [{resourceId, saveAsDraft: false}])`. New deferred setups: `calculate(type: 'deferred-revenue', amount, periods, startDate)`, `create_capsule` (type `Deferred Revenue`), post the invoice (`create_invoice`) and the recognition journals (`create_journal`) with `capsuleResourceId`, then finalize the current period's journal in the same `bulk_update_journals` call.
 
 ### Step 9: Depreciation
 
 ```
-search_fixed_assets(filter: {status: {eq: 'ACTIVE'}, depreciationMethod: {in: ['ddb', '150db']}})
+search_fixed_assets(filter: {status: {eq: 'ACTIVE'}, depreciationMethod: {eq: 'NO_DEPRECIATION'}})
 ```
 
-For Jaz-native SL assets: depreciation auto-posts; verify via `generate_fa_summary(primarySnapshotStartDate: '2025-01-01', primarySnapshotEndDate: '2025-01-31', groupBy: 'CATEGORY')` showing month's depreciation movement. For non-SL methods returned above: `plan_recipe(recipe: 'depreciation', method: 'ddb' | '150db', cost, salvageValue, usefulLifeYears, ...)` per asset, then `execute_recipe`.
+For Jaz-native SL assets: depreciation auto-posts; verify via `generate_fa_summary(primarySnapshotStartDate: '2025-01-01', primarySnapshotEndDate: '2025-01-31', groupBy: 'CATEGORY')` showing month's depreciation movement. The search above returns the assets registered with `NO_DEPRECIATION`: the register's only methods are `STRAIGHT_LINE` and `NO_DEPRECIATION`, so these are the assets depreciated by manual journal (declining balance). Confirm each one's method with the practitioner, then `calculate(type: 'depreciation', method: 'ddb' | '150db', cost, salvageValue, usefulLifeYears, frequency: 'monthly')` per asset. With `frequency: 'monthly'` the calculator's `blueprint.steps` are still ANNUAL and the monthly figures are in `schedule[]`: read this period's charge from `schedule[]`, not `blueprint.steps`. Post it with `create_journal` (Dr Depreciation Expense / Cr Accumulated Depreciation) into the asset's `Depreciation` capsule. The depreciation calculator takes no start date, so its rows are undated: ask the practitioner for the posting date and set each journal's `valueDate` yourself.
 
 ### Step 10: Employee benefit accruals
 
 If the org has headcount and tracks leave balances:
 
 ```
-plan_recipe(recipe: 'leave-accrual', employees: <headcount>, daysPerYear: <leave days per year>, dailyRate: <avg-daily-rate>, startDate: '2025-01-01', periods: 12)
+calculate(type: 'leave-accrual', employees: <headcount>, daysPerYear: <leave days per year>, dailyRate: <avg-daily-rate>, startDate: '2025-01-01', periods: 12)
 ```
 
-On first month of FY only: engine creates the scheduler and posts the first accrual. Subsequent months: scheduler emits automatically. Cross-check via `clio calc leave-accrual`.
+On first month of FY only: `create_capsule` (type `Employee Benefits`), then either post the 12 monthly journals with `capsuleResourceId`, or, since the amount is the same every month, one `create_scheduled_journal(startDate, endDate, repeat: 'MONTHLY', valueDate, schedulerEntries, capsuleResourceId)`. A schedule only fits when every period's amount is identical, and leave accrual's final period can differ from the others by a few cents (it absorbs the rounding): when it does, end the schedule one period early and post the last period as a single `create_journal` with `capsuleResourceId`. Subsequent months: the scheduler emits automatically (or finalize that month's draft). Local CLI cross-check: `clio calc leave-accrual`.
 
-### Step 11: Loan interest (finalize this period's pre-emitted journal)
+### Step 11: Loan interest (finalize this period's draft journal)
 
 For each active loan capsule (via `search_capsules(filter: {status: {eq: 'ACTIVE'}})` (capsule type is not filterable; see `building-blocks.md` § Filter limits)):
 
 1. **STOP: do not select these with a filter.** Journals cannot be narrowed to one capsule by a filter: `JournalFilter` declares no `capsuleResourceId`, and `GET /capsules/{id}` returns only `totalTransactions`, a count (measured 2026-09-07). A date+status search returns EVERY matching DRAFT in the org, including drafts a practitioner deliberately parked, so passing it to `bulk_update_journals(items: [{resourceId, saveAsDraft: false}])` finalizes unrelated work. `get_journal` (`GET /journals/{id}`) does return the link as `capsule: {resourceId, type, title}` (measured 2026-09-23), so check each candidate journal's `capsule.resourceId` against this capsule, keep only the matches, and confirm the count with the practitioner before finalizing.
 2. Should return exactly one DRAFT journal per active loan. Each is a 3-line entry (debit Loan Payable, debit Interest Expense, credit Cash) with the correct amortization split for the period.
 3. Collect resourceIds, then `bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`.
-4. Do NOT post manual loan-interest accruals; the recipe already emitted the journal with the correct split per `clio calc loan` schedule.
+4. Do NOT post a second, manual loan-interest accrual when the period's journal already exists from setup; its split follows the `calculate(type: 'loan', ...)` schedule.
 
-If a loan was newly disbursed this period: invoke `plan_recipe(recipe: 'loan', ...)` then `execute_recipe`; the disbursement (cash-in) and this period's repayment journal are both included in the engine output.
+If a loan was newly disbursed this period: `calculate(type: 'loan', principal, annualRate, termMonths, startDate)`, `create_capsule` (type `Loan Repayment`), then post the blueprint's steps with `capsuleResourceId`; the disbursement (cash-in) and every repayment journal, including this period's, are in the blueprint.
 
 ## Phase 3: Valuations
 
 ### Step 12: FX revaluation (verification only; Jaz auto-handles)
 
-**Jaz auto-handles FX revaluation for ALL foreign-currency monetary balances** (AR, AP, cash, bank, intercompany journals, term deposits, FX provisions). Period-end translation per IAS 21.23 happens inside the platform automatically. **DO NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` (would double-post).**
+**Jaz auto-handles FX revaluation for ALL foreign-currency monetary balances** (AR, AP, cash, bank, intercompany journals, term deposits, FX provisions). Period-end translation per IAS 21.23 happens inside the platform automatically. **DO NOT post the `fx-reval` calculator's result (would double-post).**
 
 This step is a verification cross-check. If the org is multi-currency:
 
@@ -173,16 +175,18 @@ clio calc fx-reval --amount <foreign> --book-rate <historical> --closing-rate <r
 
 4. Keep the verification output for audit-prep step 8 supporting schedules.
 
-Per memory rule [Bank FX is Revaluation, not Realized]: bank/cash FX uses `FX Bank Revaluation` (not Realized). AR/AP FX uses both Realized (settlement) and Unrealized (period-end translation).
+Bank FX is revaluation, not realized: bank/cash FX uses `FX Bank Revaluation` (not Realized). AR/AP FX uses both Realized (settlement) and Unrealized (period-end translation).
 
 ### Step 13: ECL review (typically quarterly, monthly check)
 
-Mental check on AR aging > 90d bucket changes. If material change vs prior month: invoke ECL recipe.
+Mental check on AR aging > 90d bucket changes. If material change vs prior month: run the ECL calculator.
 
 ```
-plan_recipe(recipe: 'ecl', buckets: <generate_aged_ar buckets, each {name, balance, rate} with rate from the org ECL loss-rate matrix>, existingProvision, startDate)
+calculate(type: 'ecl', buckets: <generate_aged_ar buckets, each {name, balance, rate} with rate from the org ECL loss-rate matrix>, existingProvision, startDate)
 ```
 
+If `adjustmentRequired` is non-zero, post it with one `create_journal` (Dr Bad Debt Expense / Cr Allowance for Doubtful Debts for an increase) into an `ECL Provision` capsule.
+
 For most SMBs, formal ECL adjustment runs in `quarter-end-close.md`. Skip in routine monthly close unless a major customer default / dispute occurred.
 
 ## Phase 4: Verification
@@ -243,8 +247,8 @@ If residuals were documented at steps 3 or 17, record the judgment after the loc
 | `quick_reconcile` | 422 `amount_mismatch` | Cascade tolerance too loose. Surface to the user; accept manually OR reject. |
 | `reconcile_invoice_receipt` | 422 `invoice_status_invalid` | Matched invoice still DRAFT. `finalize_invoice(resourceId: <id>)` first. |
 | `reconcile_*` | (any), NOT idempotent | Per `jaz-api/SKILL.md` rule 125. On 500 / network error, do NOT retry. Confirm reconciled state via `view_auto_reconciliation` or `search_bank_records(status: 'RECONCILED')` first. |
-| `plan_recipe` | 422 `account_not_found` / `contact_not_found` | Step resolution incomplete. `search_accounts` / `search_contacts`; create if missing. Halt and surface to the user. |
-| `bulk_update_journals` | 422 `journal_unbalanced` | Recipe regression. Halt; do not retry without manual review. |
+| `create_journal` (calculated step) | 422 on an account or contact id | A blueprint account name was not resolved to a real account. `search_accounts` / `search_contacts`; create if missing. Halt and surface to the user. |
+| `bulk_update_journals` | 422 `journal_unbalanced` | A draft's debits and credits differ. Halt; do not retry without manual review. |
 | `update_account` lockDate | 422 `lock_date_violated` | Open drafts in the period. Re-run step 17 gates. |
 | `update_account` lockDate | 422 `period_already_locked` | Period already closed. Confirm with the user before re-opening. |
 | FA `depreciation` posting | 0 movement when expected | Asset not `status: ACTIVE` in FA register. `update_fixed_asset(resourceId: <id>, isDraftToActive: true)` first. |

package/assets/skills/jobs/references/payment-run.md

@@ -1,8 +1,8 @@
 # Payment Run
 
-> Process outstanding supplier bills in a structured weekly or fortnightly batch through the Jaz platform tools. Walk the steps below in order, calling the named platform tools directly. (Local CLI convenience: `clio jobs payment-run` prints this same phased checklist.)
+> Process outstanding supplier bills in a structured weekly or fortnightly batch through the Jaz platform tools. Walk the steps below in order, calling the named platform tools directly.
 
-## Tools, recipes, calculators this job uses
+## Tools and calculators this job uses
 
 ### Platform tools (jaz-api)
 - **`search_bills(filter: {status: {eq: 'UNPAID'}, balanceAmount: {gt: 0}, dueDate: {lte: <cutoff>}}, sortBy: 'dueDate', sortOrder: 'ASC', limit: 200)`**, used in step 2: pull due bills (paginate via `offset` if `>200`).
@@ -16,7 +16,6 @@
 - **`finalize_bill(resourceId: <id>)`**, used in step 0 fallback: bills must be `status: APPROVED` (not `DRAFT`) before they accept payments.
 
 ### CLI tools (jaz-cli)
-- **`clio jobs payment-run --due-before <YYYY-MM-DD> --json`**: emit blueprint as JSON for downstream agent consumption.
 - **`clio jobs payment-run outstanding --due-before <YYYY-MM-DD> --currency SGD --json`**: fetch outstanding bills grouped by supplier (uses API key; equivalent to step 2 + step 4 grouping in one call).
 
 ### Cross-references
@@ -38,7 +37,7 @@ If results: surface "A payment run with prefix `PAYRUN-2025-02-28-*` already exe
 
 ## Step 1: Set the run window
 
-Pick the cutoff date for the run (the bills you'll clear are those due on or before it). (Local CLI: `clio jobs payment-run --due-before 2025-02-28` prints the phased checklist for this cutoff.)
+Pick the cutoff date for the run (the bills you'll clear are those due on or before it).
 
 ## Step 2: Identify bills
 

package/assets/skills/jobs/references/quarter-end-close.md

@@ -1,8 +1,8 @@
 # Quarter-End Close
 
-> Monthly close × 3 + quarterly extras (GST/VAT filing, formal ECL review, bonus true-up, intercompany recon, provision unwinding finalize). Walk the phases below in order, calling the named platform tools directly. (Local CLI convenience: `clio jobs quarter-end --period <YYYY-QN>` prints this same phased checklist.)
+> Monthly close × 3 + quarterly extras (GST/VAT filing, formal ECL review, bonus true-up, intercompany recon, provision unwinding finalize). Walk the phases below in order, calling the named platform tools directly.
 
-## Tools, recipes, calculators this job uses
+## Tools and calculators this job uses
 
 ### Orchestration
 - **`month-end-close.md`**: invoked 3× in standalone mode (months 1, 2, 3 of the quarter) before quarterly extras.
@@ -10,7 +10,7 @@
 ### Platform tools: quarterly extras
 - **`generate_vat_ledger(startDate: <Q-start>, endDate: <Q-end>)`**, Q1 GST/VAT filing prep: full quarterly tax ledger.
 - **`generate_aged_ar(endDate: <Q-end>)`**: Q2 ECL formal review input.
-- **`plan_recipe(recipe: 'ecl', ...)` + `execute_recipe(...)`**: Q2 ECL top-up if material.
+- **`calculate(type: 'ecl', ...)`**, then `create_capsule` + `create_journal` with `capsuleResourceId`: Q2 ECL top-up if material (the three-step flow in `building-blocks.md` § Calculated schedules).
 - **`search_journals(filter: {tags: {eq: 'bonus-accrual'}, valueDate: {between: [<Q-start>, <Q-end>]}})`**: Q3 bonus YTD pull.
 - **`create_journal(...)`**: Q3 bonus true-up adjustment (manual one-off).
 - **`search_capsules(filter: {status: {eq: 'ACTIVE'}})` (capsule type is not filterable; see `building-blocks.md` § Filter limits)**: Q4 IC reconciliation per pair of entities (multi-org coordination; see the `intercompany` recipe).
@@ -25,20 +25,20 @@
 ### Cross-references
 - Org inputs this job needs (confirm with the user when not already on file): the GST scheme (`quarterly` | `monthly` | `not-registered`), the materiality threshold, any intercompany arrangements, the bonus policy, and the ECL loss-rate matrix.
 - Sibling jobs: `month-end-close.md` (Phase 1-5 invokes 3×), `gst-vat-filing.md` (Q1 detail), `year-end-close.md` (annual, builds on this).
-- Recipes invoked: `ecl` (bad-debt / collective provision), `accrued-expense` (bonus true-up), `provision` (IAS 37), plus the manual `intercompany` pattern. See the transaction-recipes skill.
+- Calculator types used: `ecl` (bad-debt / collective provision), `accrued-expense` (bonus true-up), `provision` (IAS 37), plus the manual `intercompany` pattern. See the transaction-recipes skill for the accounting pattern behind each.
 
 ---
 
 ## Standalone vs Incremental
 
-- **Standalone (default):** Generates full plan: all month-end steps for months 1-3, then quarterly extras. Use when months haven't been closed yet.
-- **Incremental** (`--incremental`): Quarterly extras only. Use when all 3 months are already closed and locked.
+- **Standalone:** all month-end steps for months 1-3, then quarterly extras. Use when months haven't been closed yet.
+- **Incremental:** quarterly extras only. Use when all 3 months are already closed and locked.
 
 Months MUST be closed in order. Month 1 locked → Month 2 close → Month 2 locked → Month 3 close. Quarterly extras assume the 3 monthly closes are complete and current.
 
 ## Phase sequence
 
-Standalone: run all month-end steps for months 1-3 (Phase 1-5), then the quarterly extras (Phase 6), then quarterly verification + lock (Phase 7-8). Incremental (`--incremental` on the local CLI): quarterly extras only. (Local CLI: `clio jobs quarter-end --period 2025-Q1` prints the same phased checklist.)
+Standalone: run all month-end steps for months 1-3 (Phase 1-5), then the quarterly extras (Phase 6), then quarterly verification + lock (Phase 7-8). Incremental: quarterly extras only.
 
 ## Phase 1-5: Monthly closes (×3), IF standalone
 
@@ -72,11 +72,13 @@ generate_aged_ar(endDate: '2025-03-31')
 clio calc ecl --current 100000 --30d 50000 --60d 20000 --90d 10000 --120d 5000 --rates 0.5,2,5,10,50 --existing-provision <TB Allowance balance> --currency <base currency> --json
 ```
 
-If `topUpRequired > materiality threshold`:
+If `adjustmentRequired > materiality threshold`:
 
 ```
-plan_recipe(recipe: 'ecl', buckets: <[{name, balance, rate}], rate from the org ECL loss-rate matrix>, ...)
-execute_recipe(...)
+calculate(type: 'ecl', buckets: <[{name, balance, rate}], rate from the org ECL loss-rate matrix>, existingProvision: <TB Allowance balance>, startDate: '2025-03-31')
+list_capsule_types()
+create_capsule(capsuleTypeResourceId: <ECL Provision type id>, title: <blueprint.capsuleName>)
+create_journal(valueDate: '2025-03-31', autoReference: true, journalEntries: [<the calculator's journal lines, accounts resolved via search_accounts>], capsuleResourceId: <capsule id>)
 update_journal(resourceId: <ecl journal>, saveAsDraft: false)
 ```
 
@@ -112,18 +114,18 @@ For each active IAS 37 provision capsule:
 search_capsules(filter: {status: {eq: 'ACTIVE'}})
 ```
 
-Per capsule: this period's quarter-end unwinding DRAFT journals (3 monthly DRAFTs from `provision` recipe execution) should already be in the capsule. Verify and finalize:
+Per capsule: this period's quarter-end unwinding DRAFT journals (3 monthly DRAFTs posted at provision setup) should already be in the capsule. Verify and finalize:
 
 > **STOP: this step cannot be scoped, and must not be automated.** Narrowing journals to one
-> capsule is not possible: `JournalFilter` declares no `capsuleResourceId`, a journal row carries no
-> capsule link even at `view: 'full'` or on `GET /journals/{id}`, and `GET /capsules/{id}` returns
-> only `totalTransactions`, a count (all measured 2026-09-07). A search by date and status alone
+> capsule is not possible: `JournalFilter` declares no `capsuleResourceId`, a journal search row carries no
+> capsule link even at `view: 'full'`, and `GET /capsules/{id}` returns
+> only `totalTransactions`, a count (measured 2026-09-07). `get_journal` on one journal does return its `capsule` (`{resourceId, type, title}`, verified 2026-10-02), so a candidate can be confirmed one at a time. A search by date and status alone
 > returns **every** matching DRAFT in the org, including drafts a practitioner deliberately parked,
 > so feeding it to `bulk_update_journals(items: [{resourceId, saveAsDraft: false}])` or `delete_journal` would finalize or
 > destroy unrelated work. Surface the capsule and its expected journal count to the practitioner and
 > let them identify the journals; do not select them with a filter.
 
-If the user determines remeasurement is needed (cash-flow estimate changed, discount rate moved): recompute, post the adjustment, reverse the remaining DRAFT unwinding journals, and re-execute the `provision` recipe with the new inputs.
+If the user determines remeasurement is needed (cash-flow estimate changed, discount rate moved): recompute, post the adjustment, delete the remaining DRAFT unwinding journals, then run `calculate(type: 'provision', amount, annualRate, termMonths, startDate)` with the new inputs and post the new unwinding journals into the capsule.
 
 ## Phase 7: Quarterly verification
 
@@ -156,10 +158,10 @@ update_account(resourceId: <CoA root>, lockDate: '2025-03-31')
 |--------|-------|----------|
 | Phase 1-5 (standalone) | Months not all closed | Months incomplete. Route to missing `month-end-close.md`. Run quarterly extras only once all 3 months are locked. |
 | Q1 verification | Tax ledger ≠ sum of GST per invoice/bill | Likely tax-profile assignment errors. Audit each invoice / bill for correct tax profile. Quick Fix: `quick_fix_line_items(entity: 'invoices' \| 'bills', ...)` on the affected lines, since the tax profile sits on each line. |
-| Q2 ECL recipe | 422 `account_not_found` | `Allowance for Doubtful Debts` missing. Create via `create_account(name: 'Allowance for Doubtful Debts', code: <unused account code>, accountType: 'Current Asset')`. |
-| Q3 | YTD accrual mismatches monthly recipe expectations | Likely a manual journal posted directly to Bonus Liability (not via recipe). Audit `generate_general_ledger(accountResourceIds: [<Bonus Liability>], startDate: <FY-start>, endDate: <today>)`. |
+| Q2 ECL journal | 422 on the allowance account id | `Allowance for Doubtful Debts` missing. Create via `create_account(name: 'Allowance for Doubtful Debts', code: <unused account code>, accountType: 'Current Asset')`. |
+| Q3 | YTD accrual mismatches the monthly schedule | Likely a manual journal posted directly to Bonus Liability (outside the schedule). Audit `generate_general_ledger(accountResourceIds: [<Bonus Liability>], startDate: <FY-start>, endDate: <today>)`. |
 | Q4 IC recon | Entity A IC Receivable ≠ Entity B IC Payable (sign-flipped) | See the `intercompany` recipe error table. Common causes: timing, FX confusion, posting skipped in one entity. |
-| Q5 | Provision DRAFTs missing for the quarter | Recipe wasn't executed at provision setup. Re-run the `provision` recipe with current inputs; the engine emits the unwinding schedule for the remaining periods. |
+| Q5 | Provision DRAFTs missing for the quarter | The unwinding schedule was not posted at provision setup. Run `calculate(type: 'provision', ...)` with current inputs and post the unwinding journals for the remaining periods into the capsule. |
 
 ---
 

package/assets/skills/jobs/references/supplier-recon.md

@@ -1,8 +1,8 @@
 # Supplier Statement Reconciliation
 
-> Compare AP balance per Jaz vs supplier's statement. Identify missing bills, duplicate payments, pricing discrepancies, timing differences. Walk the steps below in order, calling the named platform tools directly. (Local CLI convenience: `clio jobs supplier-recon` prints this same phased checklist.)
+> Compare AP balance per Jaz vs supplier's statement. Identify missing bills, duplicate payments, pricing discrepancies, timing differences. Walk the steps below in order, calling the named platform tools directly.
 
-## Tools, recipes, calculators this job uses
+## Tools and calculators this job uses
 
 ### Platform tools
 - **`search_contacts(filter: {supplier: true, name: {eq: <supplier>}})`** (step 1): resolve the supplier resourceId. Use fuzzy match if exact fails.
@@ -34,7 +34,7 @@
 
 ## Steps
 
-Walk steps 1-8 below. (Local CLI: `clio jobs supplier-recon --supplier "<name>" --period 2025-01` prints the same phased checklist.)
+Walk steps 1-8 below.
 
 ## Step 1: Resolve supplier
 
@@ -94,7 +94,7 @@ Practitioner provides the supplier's statement (PDF, email, paper). Per-line-ite
 
 | Discrepancy | Likely cause | Fix |
 |-------------|--------------|-----|
-| Bill on supplier statement, not in Jaz | Missed bill (most common) | `mcp magic create --file <statement-pdf>` extracts the missing bill, OR manual `create_bill(...)`; pay if owed. |
+| Bill on supplier statement, not in Jaz | Missed bill (most common) | `create_bt_from_attachment` (local CLI: `clio magic create --file <bill-pdf> --type bill`) extracts the missing bill from its PDF, OR manual `create_bill(...)`; pay if owed. |
 | Bill in Jaz, not on supplier statement | Supplier hasn't issued / lost the invoice | Verify with supplier; if confirmed bogus, `delete_bill` (DRAFT) OR `create_supplier_credit_note` (if ACTIVE). |
 | Different amounts on same reference | Pricing dispute | Practitioner contacts supplier for clarification. Possible adjustment journal post-resolution. |
 | Bill paid per Jaz, supplier says unpaid | Bank reconciliation gap | Pull bank statement for the payment date; verify the wire/cheque cleared. If cleared, send remittance proof to supplier. |
@@ -139,7 +139,7 @@ Keep, per supplier:
 
 - **Run for major suppliers only.** Top 10 suppliers by total spend cover 80% of AP risk. Mid + tail suppliers: skip or batch annually.
 - **Quarterly cadence** for major suppliers; **annual** for tier-2.
-- **Statement format varies wildly.** PDF / Excel / paper. `mcp magic create` works on most PDFs but not all; fallback to manual.
+- **Statement format varies wildly.** PDF / Excel / paper. `clio magic create` works on most PDFs but not all; fallback to manual.
 - **Pre-payment-run check.** Run supplier-recon BEFORE `payment-run.md` to capture any disputed bills (don't pay) and missing bills (post + pay this run).
 
 ---