jaz-clio 5.65.0 → 5.65.1

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

@@ -6,11 +6,11 @@
 
 ### Platform tools
 - **`search_fixed_assets(filter: {status: {in: ['ACTIVE', 'DISPOSED', 'DISCARDED']}}, limit: 200)`** — step 1: enumerate FAs. Paginate.
-- **`get_fixed_asset(resourceId: <id>)`** — step 2: per-asset detail (cost, acquisitionDate, usefulLifeMonths, depreciationMethod, salvageValue, NBV).
-- **`generate_fa_summary(period_end: <date>)`** — step 3: aggregate FA register at period end.
-- **`generate_fa_recon_summary(period_start: <year-start>, period_end: <year-end>)`** — step 3: reconcile movement (opening + additions − disposals − depreciation = closing).
-- **`generate_general_ledger(accountResourceId: <FA category GL>, period_start, period_end)`** — step 4: per-FA-category GL movement vs FA register.
-- **`mark_fixed_asset_sold(resourceId: <id>, disposalDate, disposalProceeds)`** — 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).
+- **`get_fixed_asset(resourceId: <id>)`** — step 2: per-asset detail (purchaseAmount, purchaseDate, depreciationStartDate, effectiveLife in months, depreciationMethod, depreciableValueResidualAmount, NBV).
+- **`generate_fa_summary(primarySnapshotStartDate: <period-start>, primarySnapshotEndDate: <period-end>, groupBy: 'CATEGORY')`** — step 3: aggregate FA register at period end.
+- **`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.
 
@@ -42,7 +42,7 @@ Paginate via offset. For year-end review: include DISPOSED and DISCARDED (dispos
 
 For each ACTIVE asset, flag for practitioner attention:
 - **Fully depreciated** (`NBV == salvageValue` per FA summary): consider disposal if no longer in use; consider impairment review per IAS 36 if NBV > recoverable amount.
-- **Recently acquired without `usefulLifeMonths`**: depreciation can't run; halt and surface.
+- **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.
@@ -50,21 +50,21 @@ For each ACTIVE asset, flag for practitioner attention:
 ## Step 3 — FA register reconciliation
 
 ```
-generate_fa_summary(period_end: '2025-12-31')
-generate_fa_recon_summary(period_start: '2025-01-01', period_end: '2025-12-31')
+generate_fa_summary(primarySnapshotStartDate: '2025-01-01', primarySnapshotEndDate: '2025-12-31', groupBy: 'CATEGORY')
+generate_fa_recon_summary(primarySnapshotStartDate: '2025-01-01', primarySnapshotEndDate: '2025-12-31')
 ```
 
 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(accountResourceId: <FA category cost GL>, period_start, period_end)`. Common: a disposal posted via the `asset-disposal` recipe but `update_fixed_asset(status: 'DISPOSED')` step 5 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 posted via the `asset-disposal` recipe but the step 5 `mark_fixed_asset_sold` / `discard_fixed_asset` was missed — Jaz continues auto-depreciating.
 
 ## Step 4 — Depreciation cross-check
 
 For each ACTIVE SL asset (Jaz auto-depreciates):
-- Pull FA's expected annual depreciation: `(cost - salvage) / (usefulLifeMonths / 12)`.
-- Compare to actual `generate_general_ledger(accountResourceId: <Depreciation Expense for this category>, period_start: <year-start>, period_end: <year-end>)` movement.
+- Pull FA's expected annual depreciation: `(purchaseAmount - depreciableValueResidualAmount) / (effectiveLife / 12)`.
+- 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):
@@ -79,13 +79,10 @@ For each disposal identified in step 2:
 
 ```
 plan_recipe(
-  // Note: gl*, capsuleType, capsuleName, bankAccountResourceId, vendor, customer below are illustrative — auto-resolved at execute time from the CoA, not real plan_recipe params.
+  // 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,
-  ...,
-  fixedAssetResourceId: <asset id>,
-  capsuleType: 'Asset Disposal',
-  capsuleName: 'Disposal — <asset name> — <disposal date>'
+  ...
 )
 execute_recipe(...)
 update_journal(resourceId: <disposal journal id>, saveAsDraft: false)
@@ -93,7 +90,9 @@ update_journal(resourceId: <disposal journal id>, saveAsDraft: false)
 
 Then the manual FA-register status update (engine-skipped — see the `asset-disposal` recipe):
 ```
-update_fixed_asset(resourceId: <asset id>, status: 'DISPOSED', disposalDate, disposalProceeds)
+mark_fixed_asset_sold(resourceId: <asset id>, depreciationEndDate, assetDisposalGainLossAccountResourceId, saleBusinessTransactionType, saleItemResourceId)
+// or, for a write-off with no sale:
+discard_fixed_asset(resourceId: <asset id>, disposalDate, depreciationEndDate)
 ```
 
 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.
@@ -109,7 +108,7 @@ For assets at salvage value AND no longer in use:
 
 For each FA category (e.g., Vehicles, Office Equipment, Computers, Buildings):
 ```
-generate_general_ledger(accountResourceId: <FA cost GL>, period_start: '2025-01-01', period_end: '2025-12-31', groupBy: 'ACCOUNT')
+generate_general_ledger(accountResourceIds: [<FA cost GL>], startDate: '2025-01-01', endDate: '2025-12-31', groupBy: 'ACCOUNT')
 ```
 
 Group by capsule shows per-asset / per-disposal trail. Auditor sample-test will pick 2-3 assets per category and trace GL → original purchase bill → FA registration → depreciation history → disposal (if any).
@@ -133,7 +132,7 @@ These feed `audit-prep.md` step 8 supporting schedules.
 | 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 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 `acquisitionDate`). Reconcile per asset. |
+| 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. |
 

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

@@ -5,13 +5,13 @@
 ## Tools, recipes, calculators this job uses
 
 ### Platform tools
-- **`generate_vat_ledger(period_start: <period-start>, period_end: <period-end>)`** — step 1: the canonical tax ledger. Returns input + output tax totals + per-tax-profile breakdown.
+- **`generate_vat_ledger(startDate: <period-start>, endDate: <period-end>)`** — step 1: the canonical tax ledger. Returns input + output tax totals + per-tax-profile breakdown.
 - **`search_tax_profiles(filter: {})`** — step 2 setup verification: confirm all expected tax profiles exist (`SR`, `ZR`, `ES`, `IES`, `OS`, `TX`, `BL`, `OP`, `EP`, `RC` for SG; `VAT-RC`, `VAT-EXP`, `VAT-ZR`, `VAT-EXM`, `VAT-EXC` for PH).
 - **`search_invoices(filter: {valueDate: {between: [<period-start>, <period-end>]}}, limit: 200)`** — step 3 output-tax detail: per-invoice GST cross-check against tax ledger.
 - **`search_bills(filter: {valueDate: {between: [<period-start>, <period-end>]}, status: {neq: 'DRAFT'}}, limit: 200)`** — step 4 input-tax detail: per-bill GST cross-check, with blocked-input filter.
 - **`quick_fix_line_items(entity: 'invoices' | 'bills', lineItemResourceIds, attributes)`** — step 5 corrections: re-assign the tax profile on the affected lines if errors are found. The tax profile sits on each line, so the fix is at line level.
 - **`download_export(exportType: 'analysis-exchange-rate-audit', startDate, endDate)`** — step 6 pre-filing check: FX rates outside expected band can shift GST on FX invoices.
-- **`generate_trial_balance(period_end: <period-end>)`** — step 7 GST account reconciliation: `GST Control` / `Input Tax Recoverable` / `Output Tax Payable` accounts.
+- **`generate_trial_balance(endDate: <period-end>)`** — step 7 GST account reconciliation: `GST Control` / `Input Tax Recoverable` / `Output Tax Payable` accounts.
 
 ### Cross-references
 - Org inputs this job needs (confirm with the user when not already on file): the GST scheme, the GST registration number, and the country code (`SG` | `PH`).
@@ -27,7 +27,7 @@ Walk steps 1-8 below. (Local CLI: `clio jobs gst-vat --period 2025-Q1` prints th
 ## Step 1 — Pull the tax ledger
 
 ```
-generate_vat_ledger(period_start: '2025-01-01', period_end: '2025-03-31')
+generate_vat_ledger(startDate: '2025-01-01', endDate: '2025-03-31')
 ```
 
 Save the quarter's VAT ledger. Returns:
@@ -126,14 +126,14 @@ For PH (country code `PH`): also run `download_export(exportType: 'analysis-anom
 ## Step 7 — GST account reconciliation
 
 ```
-generate_trial_balance(period_end: '2025-03-31')
+generate_trial_balance(endDate: '2025-03-31')
 ```
 
 For SG: balance['GST Control'] should equal tax-ledger's `netPayable` for the quarter. Pre-existing balance from prior quarter (carried forward) must be netted.
 
 For PH: separate accounts for Input VAT Recoverable + Output VAT Payable; verify each independently.
 
-If TB doesn't tie to tax ledger: likely a manual journal posted directly to GST accounts (bypassing the per-transaction tax-profile). Audit via `generate_general_ledger(accountResourceId: <GST Control>, period_start, period_end)` — surface any non-source-system entries.
+If TB doesn't tie to tax ledger: likely a manual journal posted directly to GST accounts (bypassing the per-transaction tax-profile). Audit via `generate_general_ledger(accountResourceIds: [<GST Control>], startDate, endDate)` — surface any non-source-system entries.
 
 ## Step 8 — Filing summary
 

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

@@ -8,7 +8,7 @@
 - **`search_invoices(filter: {valueDate: {between: [<period-start>, <period-end>]}}, sortBy: 'valueDate', sortOrder: 'ASC', limit: 200)`** — step 1: confirm sales invoices entered. Paginate via `offset`.
 - **`search_bills(filter: {valueDate: {between: [<period-start>, <period-end>]}}, ...)`** — step 2: confirm purchase bills entered.
 - **`search_bank_records(accountResourceId: <id>, status: 'UNRECONCILED', startDate: <from>, endDate: <to>)`** — step 3: pull unreconciled bank statement entries per account.
-- **`generate_aged_ar(period_end: <date>)` / `generate_aged_ap(period_end: <date>)`** — steps 4-5: aging reports tied to TB AR / AP balances.
+- **`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.
@@ -25,9 +25,9 @@
 - **`quick_reconcile(...)` / `reconcile_direct_cash_entry(...)` / `reconcile_cash_journal(...)` / `reconcile_manual_journal(...)` / `reconcile_cash_transfer(...)` / `reconcile_invoice_receipt(...)` / `reconcile_bill_receipt(...)`** — step 3: per matched pair from the cascade.
 
 ### Platform tools — verification + close
-- **`generate_trial_balance(period_end: <date>)`** — step 14: master reconciliation.
-- **`generate_profit_and_loss(period_start, period_end)`** — step 15.
-- **`generate_balance_sheet(period_end)`** — step 16.
+- **`generate_trial_balance(endDate: <date>)`** — step 14: master reconciliation.
+- **`generate_profit_and_loss(startDate, endDate)`** — step 15.
+- **`generate_balance_sheet(snapshotDate)`** — step 16.
 - **`search_journals(filter: {status: {eq: 'DRAFT'}, valueDate: {between: [<period-start>, <period-end>]}})`** — step 17: gate on zero drafts.
 - **`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.
@@ -77,15 +77,15 @@ For each bank account:
 2. `search_bank_records(accountResourceId: <bank account resourceId>, status: 'UNRECONCILED', startDate: '2025-01-01', endDate: '2025-01-31', limit: 200, sortBy: 'valueDate', sortOrder: 'ASC')`.
 3. If results: drive the 5-phase cascade matcher (Step 4 in `bank-recon.md`; local CLI: `clio jobs bank-recon match --input <records> --tolerance 0.01 --date-window 14 --json`). For each match, invoke the matching `reconcile_*` tool.
 4. `view_auto_reconciliation(bankStatementEntryResourceIds: [<id>, ...], recommendationType: 'MAGIC_MATCH')` — READ-ONLY suggestions for residuals (per-entry; get ids from `search_bank_records`, status `UNRECONCILED`); commit via `quick_reconcile` / `apply_bank_rule` / per-entry `reconcile_*`.
-5. `generate_bank_recon_summary(period_end: '2025-01-31', accountResourceId: <id>)`. Confirm `unreconciledCount == 0` OR document the residuals for the period and surface to the user.
+5. `generate_bank_recon_summary(bankAccountResourceId: <id>, primarySnapshotStartDate: '2025-01-01', primarySnapshotEndDate: '2025-01-31')`. Confirm `unreconciledCount == 0` OR document the residuals for the period and surface to the user.
 
 Full detail in `bank-recon.md`. NOT idempotent — see error table.
 
 ### Steps 4-5 — AR / AP aging
 
 ```
-generate_aged_ar(period_end: '2025-01-31')
-generate_aged_ap(period_end: '2025-01-31')
+generate_aged_ar(endDate: '2025-01-31')
+generate_aged_ap(endDate: '2025-01-31')
 ```
 
 Use `endDate` (rule 36 — point-in-time, not period-range). Assert: aging totals match `generate_trial_balance` AR/AP lines within the org's materiality threshold. Flag > 60d for credit-control / payment-priority. Disputed bills exit the active aging — annotate for the user.
@@ -98,26 +98,26 @@ 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>, glAccount: <accrual GL account>, vendor: <accrual vendor>, valueDate: '2025-01-31', reversalDate: '2025-02-01')`.
+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.
 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(period_end: '2025-01-31')`. Sum credit movements against accrual liability accounts. Verify `|sum - expected| ≤ materiality threshold`.
+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)
 
 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(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.
+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.
 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 is then in the bulk_finalize_drafts queue above.
+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).
 
 ### Step 8 — Deferred revenue recognition
 
-Mirror of step 7. Existing `Deferred Revenue` capsules: search for this period's DRAFT journal in each, then `bulk_finalize_drafts`. New deferred setups: `plan_recipe(recipe: 'deferred-revenue', ...)` then handle the current period's journal in the same bulk_finalize.
+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.
 
 ### Step 9 — Depreciation
 
@@ -125,14 +125,14 @@ Mirror of step 7. Existing `Deferred Revenue` capsules: search for this period's
 search_fixed_assets(filter: {status: {eq: 'ACTIVE'}, depreciationMethod: {in: ['ddb', '150db']}})
 ```
 
-For Jaz-native SL assets: depreciation auto-posts; verify via `generate_fa_summary(period_end: '2025-01-31')` showing month's depreciation movement. For non-SL methods returned above: `plan_recipe(recipe: 'depreciation', method: 'ddb' | '150db', cost, salvage, life, ...)` 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. For non-SL methods returned above: `plan_recipe(recipe: 'depreciation', method: 'ddb' | '150db', cost, salvageValue, usefulLifeYears, ...)` per asset, then `execute_recipe`.
 
 ### Step 10 — Employee benefit accruals
 
 If the org has headcount and tracks leave balances:
 
 ```
-plan_recipe(recipe: 'leave-accrual', headcount: <headcount>, daysPerEmployee: <leave days per year>, dailyRate: <avg-daily-rate>, startDate: '2025-01-01', termMonths: 12)
+plan_recipe(recipe: '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`.
@@ -141,7 +141,7 @@ On first month of FY only — engine creates the scheduler and posts the first a
 
 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(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.
+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.
@@ -159,7 +159,7 @@ This step is a verification cross-check. If the org is multi-currency:
 1. Pull what Jaz auto-posted to FX accounts during the period:
 ```
 search_accounts(filter: {name: {in: ['FX Unrealized Gain', 'FX Unrealized Loss', 'FX Bank Revaluation']}})
-generate_general_ledger(period_end: '2025-01-31', accountResourceIds: [<FX account ids>], groupBy: 'ACCOUNT')
+generate_general_ledger(startDate: '2025-01-01', endDate: '2025-01-31', accountResourceIds: [<FX account ids>], groupBy: 'ACCOUNT')
 ```
 
 2. For each foreign-currency monetary balance at period end (from a separate `generate_general_ledger` filtered to non-base-currency accounts), independently compute:
@@ -180,7 +180,7 @@ Per memory rule [Bank FX is Revaluation, not Realized]: bank/cash FX uses `FX Ba
 Mental check on AR aging > 90d bucket changes. If material change vs prior month: invoke ECL recipe.
 
 ```
-plan_recipe(recipe: 'ecl', receivables: <generate_aged_ar.buckets>, ratesPerBucket: <org ECL loss-rate matrix>)
+plan_recipe(recipe: 'ecl', buckets: <generate_aged_ar buckets, each {name, balance, rate} with rate from the org ECL loss-rate matrix>, existingProvision, startDate)
 ```
 
 For most SMBs, formal ECL adjustment runs in `quarter-end-close.md`. Skip in routine monthly close unless a major customer default / dispute occurred.
@@ -190,7 +190,7 @@ For most SMBs, formal ECL adjustment runs in `quarter-end-close.md`. Skip in rou
 ### Step 14 — Trial balance
 
 ```
-generate_trial_balance(period_end: '2025-01-31')
+generate_trial_balance(endDate: '2025-01-31')
 ```
 
 Save the close trial balance for the period (you'll diff next month against it). Assert:
@@ -203,8 +203,8 @@ Save the close trial balance for the period (you'll diff next month against it).
 ### Steps 15-16 — P&L + Balance Sheet
 
 ```
-generate_profit_and_loss(period_start: '2025-01-01', period_end: '2025-01-31')
-generate_balance_sheet(period_end: '2025-01-31')
+generate_profit_and_loss(startDate: '2025-01-01', endDate: '2025-01-31')
+generate_balance_sheet(snapshotDate: '2025-01-31')
 ```
 
 Save both. Assert: BS Total Assets == Total Liabilities + Total Equity. P&L net profit ties to BS Equity Movement.
@@ -219,7 +219,7 @@ search_invoices(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-0
 search_bills(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-01', '2025-01-31']}})
 ```
 
-All three must return zero. If any rows: classify per practitioner judgment, then `bulk_finalize_drafts` for the keep-set OR delete via `delete_journal` / `delete_invoice` / `delete_bill`. Record the judgment: `jot(kind: SCOPE)` naming which drafts were finalized, which were deleted, and the rule applied.
+All three must return zero. If any rows: classify per practitioner judgment, then finalize the keep-set (`bulk_update_journals` for journals, `bulk_finalize_drafts` for invoices and bills) OR delete via `delete_journal` / `delete_invoice` / `delete_bill`. Record the judgment: `jot(kind: SCOPE)` naming which drafts were finalized, which were deleted, and the rule applied.
 
 ## Phase 5 — Lock
 
@@ -244,10 +244,10 @@ If residuals were documented at steps 3 or 17, record the judgment after the loc
 | `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_finalize_drafts` | 422 `journal_unbalanced` | Recipe regression. Halt; do not retry without manual review. |
+| `bulk_update_journals` | 422 `journal_unbalanced` | Recipe regression. 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>, status: 'ACTIVE')` first. |
+| 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

@@ -6,10 +6,10 @@
 
 ### 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`).
-- **`generate_aged_ap(period_end: <cutoff>)`** — used in step 3: total-AP cross-check; flag bills in 60d+ aging buckets.
-- **`generate_bank_balance_summary(period_end: <cutoff>)`** — used in step 5: confirm cash availability before approving the batch.
+- **`generate_aged_ap(endDate: <cutoff>)`** — used in step 3: total-AP cross-check; flag bills in 60d+ aging buckets.
+- **`generate_bank_balance_summary(primarySnapshotDate: <cutoff>)`** — used in step 5: confirm cash availability before approving the batch.
 - **`get_contact(resourceId: <contactResourceId>)`** — used in step 4 (per supplier): pull payment terms / preferred payment method / bank details (especially `taxId`, `bankAccountNumber`, `bicSwift` for GIRO file generation).
-- **`create_bill_payment(billResourceId: <id>, payments: [{...}])`** — used in step 6: post the payment per bill. NO BATCH PAYMENT ENDPOINT yet — one POST per bill.
+- **`pay_bill(resourceId: <id>, paymentAmount, transactionAmount, accountResourceId, valueDate, ...)`** — used in step 6: post the payment per bill. NO BATCH PAYMENT ENDPOINT yet — one POST per bill.
 - **`search_payments(filter: {businessTransactionReference: {startWith: <run-prefix>}, valueDate: {eq: <run-date>}})`** — used in step 8: idempotency / verification check (re-running the run won't duplicate-pay if all references match).
 
   > **The field and the operator are both exact.** `search_payments` hits `POST /cashflow-transactions/search` → `TransactionsFilter`, which declares no `additionalProperties`, so an undeclared field is rejected outright rather than ignored. It has **no `reference`** (that is `businessTransactionReference`) and `StringExpression` has **no `startsWith`** — the prefix operator is spelled **`startWith`**, no "s". Until 5.55.3 this line asked for both wrong names, so the idempotency check — the step standing between a re-run and paying every supplier twice — could not return anything. Use `startWith`, not `contains`: measured on the sandbox 2026-09-07, `contains: 'PR-'` matched 3 rows that do **not** start with that prefix, and a looser match here silently widens what the run treats as already-paid.
@@ -61,7 +61,7 @@ For each bill, also collect: `contactResourceId`, `currency`, `originalAmount`,
 ## Step 3 — AP aging cross-check
 
 ```
-generate_aged_ap(period_end: '2025-02-28')
+generate_aged_ap(endDate: '2025-02-28')
 ```
 
 Verify: `sum(derived outstanding) ≈ generate_aged_ap.totalOutstanding` (within the materiality threshold). Mismatch indicates pending bills in non-`UNPAID` status (e.g., `PARTIALLY_PAID`) that need separate handling — surface to the user.
@@ -79,12 +79,12 @@ Suppliers prefer one consolidated payment per run. Multi-currency suppliers need
 ## Step 5 — Cash availability gate
 
 ```
-generate_bank_balance_summary(period_end: '2025-02-28')
+generate_bank_balance_summary(primarySnapshotDate: '2025-02-28')
 ```
 
 For each `bankAccountResourceId` you'll pay from: confirm `availableBalance >= sum of payments to be drawn from it`. If insufficient: defer the bottom of the priority stack to the next run; surface the deferred list to practitioner with explanation.
 
-Apply the org's cash-buffer policy (default: 14 days operating expenses) — never drain to zero. Compute buffer-required from last 30 days' opex via `generate_profit_and_loss(period_start: <-30d>, period_end: <today>)`.
+Apply the org's cash-buffer policy (default: 14 days operating expenses) — never drain to zero. Compute buffer-required from last 30 days' opex via `generate_profit_and_loss(startDate: <-30d>, endDate: <today>)`.
 
 Record the judgment: `jot(kind: SCOPE)` naming the deferred bills and the cash-buffer rule applied.
 
@@ -93,16 +93,14 @@ Record the judgment: `jot(kind: SCOPE)` naming the deferred bills and the cash-b
 For each approved bill (one POST per bill — no batch endpoint):
 
 ```
-create_bill_payment(
-  billResourceId: <id>,
-  payments: [{
-    paymentAmount: 5350.00,
-    transactionAmount: 5350.00,
-    accountResourceId: <bank-account-resourceId>,
-    paymentMethod: 'BANK_TRANSFER',
-    reference: 'PAYRUN-2025-02-28-001',
-    valueDate: '2025-02-28'
-  }]
+pay_bill(
+  resourceId: <id>,
+  paymentAmount: 5350.00,
+  transactionAmount: 5350.00,
+  accountResourceId: <bank-account-resourceId>,
+  paymentMethod: 'BANK_TRANSFER',
+  reference: 'PAYRUN-2025-02-28-001',
+  valueDate: '2025-02-28'
 )
 ```
 
@@ -116,10 +114,10 @@ create_bill_payment(
 
 ## Step 7 — Verify
 
-After all `create_bill_payment` calls succeed:
+After all `pay_bill` calls succeed:
 
 ```
-generate_aged_ap(period_end: '2025-02-28')
+generate_aged_ap(endDate: '2025-02-28')
 search_payments(filter: {businessTransactionReference: {startWith: 'PAYRUN-2025-02-28-'}, valueDate: {eq: '2025-02-28'}})
 ```
 
@@ -129,7 +127,7 @@ Assert:
 - `search_payments` returns N rows where N = bills paid in step 6.
 
 ```
-generate_bank_balance_summary(period_end: '2025-02-28')
+generate_bank_balance_summary(primarySnapshotDate: '2025-02-28')
 ```
 
 Assert: per-account balance reduced by `sum(paymentAmount per accountResourceId)`. Cross-reference to actual bank statement when it arrives — this is the next-day bank-recon job.
@@ -140,11 +138,11 @@ Assert: per-account balance reduced by `sum(paymentAmount per accountResourceId)
 
 | Source | Error | Recovery |
 |--------|-------|----------|
-| `create_bill_payment` | 422 `bill_not_approved` | Bill is `DRAFT`. `finalize_bill(resourceId: <id>)` first, then retry. Do NOT pay drafts. |
-| `create_bill_payment` | 422 `currency_mismatch` | `paymentAmount` currency ≠ bank account currency. Either pay from the matching-currency bank account, or model as FX (different `paymentAmount` and `transactionAmount`). |
-| `create_bill_payment` | 422 `bill_already_paid` | Bill went `PAID` since step 2. Re-run `search_bills` for fresh state; remove from batch. |
-| `create_bill_payment` | 422 `lock_date_violated` | `valueDate` is in a locked period. Either lift the lock via `update_account` lock_date OR adjust `valueDate` to the next open period. |
-| `create_bill_payment` | 500 mid-run | Some payments succeeded; others didn't. NOT idempotent — re-running the loop creates duplicates. Use `search_payments` with the run prefix to identify what succeeded; resume from the next unprocessed bill. Record the judgment: `jot(kind: RECOVERY)` naming the resume point and the bills already paid. |
+| `pay_bill` | 422 `bill_not_approved` | Bill is `DRAFT`. `finalize_bill(resourceId: <id>)` first, then retry. Do NOT pay drafts. |
+| `pay_bill` | 422 `currency_mismatch` | `paymentAmount` currency ≠ bank account currency. Either pay from the matching-currency bank account, or model as FX (different `paymentAmount` and `transactionAmount`). |
+| `pay_bill` | 422 `bill_already_paid` | Bill went `PAID` since step 2. Re-run `search_bills` for fresh state; remove from batch. |
+| `pay_bill` | 422 `lock_date_violated` | `valueDate` is in a locked period. Either lift the lock via `update_account` lock_date OR adjust `valueDate` to the next open period. |
+| `pay_bill` | 500 mid-run | Some payments succeeded; others didn't. NOT idempotent — re-running the loop creates duplicates. Use `search_payments` with the run prefix to identify what succeeded; resume from the next unprocessed bill. Record the judgment: `jot(kind: RECOVERY)` naming the resume point and the bills already paid. |
 | `generate_aged_ap` | Total mismatch with `search_bills` | Likely `PARTIALLY_PAID` bills excluded from `search_bills` filter. Add `status: {in: ['UNPAID', 'PARTIALLY_PAID']}` and retry. |
 
 ---

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

@@ -8,14 +8,14 @@
 - **`month-end-close.md`** — invoked 3× in standalone mode (months 1, 2, 3 of the quarter) before quarterly extras.
 
 ### Platform tools — quarterly extras
-- **`generate_vat_ledger(period_start: <Q-start>, period_end: <Q-end>)`** — Q1 GST/VAT filing prep: full quarterly tax ledger.
-- **`generate_aged_ar(period_end: <Q-end>)`** — Q2 ECL formal review input.
+- **`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.
 - **`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).
 - **`search_capsules(filter: {status: {eq: 'ACTIVE'}})` (capsule type is not filterable — see `building-blocks.md` § Filter limits) + `bulk_update_journals(items: [{resourceId: <id>, saveAsDraft: false}, ...])`** — Q5 finalize each provision capsule's quarter-end DRAFT unwinding journals.
-- **`generate_trial_balance(period_end: <Q-end>)`** — verification.
+- **`generate_trial_balance(endDate: <Q-end>)`** — verification.
 - **`update_account(resourceId: <CoA root>, lockDate: <Q-end>)`** — final lock.
 
 ### Calculators (cross-check, no API key needed)
@@ -49,7 +49,7 @@ Invoke `month-end-close.md` job for each of months 1, 2, 3 of the quarter. By en
 ### Q1 — GST/VAT filing preparation
 
 ```
-generate_vat_ledger(period_start: '2025-01-01', period_end: '2025-03-31')
+generate_vat_ledger(startDate: '2025-01-01', endDate: '2025-03-31')
 ```
 
 Save the quarter's VAT ledger. Verify:
@@ -68,14 +68,14 @@ Full step-by-step in `gst-vat-filing.md`.
 ### Q2 — ECL formal review
 
 ```
-generate_aged_ar(period_end: '2025-03-31')
+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`:
 
 ```
-plan_recipe(recipe: 'ecl', receivables: <buckets>, ratesPerBucket: <rates from the org ECL loss-rate matrix>, ...)
+plan_recipe(recipe: 'ecl', buckets: <[{name, balance, rate}], rate from the org ECL loss-rate matrix>, ...)
 execute_recipe(...)
 update_journal(resourceId: <ecl journal>, saveAsDraft: false)
 ```
@@ -97,10 +97,10 @@ Sum YTD accruals. Re-estimate full-year bonus per current performance data. If r
 If the org has intercompany arrangements:
 
 For each arrangement (per pair of entities):
-1. Per-entity TB pull: `generate_trial_balance(period_end: '2025-03-31')` under EACH entity's org credentials (multi-org work — see the `intercompany` recipe).
+1. Per-entity TB pull: `generate_trial_balance(endDate: '2025-03-31')` under EACH entity's org credentials (multi-org work — see the `intercompany` recipe).
 2. Verify `Entity A's IC Receivable balance == Entity B's IC Payable balance` (sign flipped).
 3. Investigate discrepancies (timing, FX, missing posting).
-4. If settling balances: post `create_cash_out_entry` in payer org + `create_cash_in_entry` (or invoice payment) in payee org.
+4. If settling balances: post `create_cash_out` in payer org + `create_cash_in` (or invoice payment) in payee org.
 
 Full pattern in the `intercompany` recipe.
 
@@ -119,7 +119,7 @@ Per capsule: this period's quarter-end unwinding DRAFT journals (3 monthly DRAFT
 > 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
 > returns **every** matching DRAFT in the org, including drafts a practitioner deliberately parked,
-> so feeding it to `bulk_update_journals(saveAsDraft: false)` or `delete_journal` would finalize or
+> 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.
 
@@ -128,9 +128,9 @@ If the user determines remeasurement is needed (cash-flow estimate changed, disc
 ## Phase 7 — Quarterly verification
 
 ```
-generate_trial_balance(period_end: '2025-03-31')
-generate_profit_and_loss(period_start: '2025-01-01', period_end: '2025-03-31')
-generate_balance_sheet(period_end: '2025-03-31')
+generate_trial_balance(endDate: '2025-03-31')
+generate_profit_and_loss(startDate: '2025-01-01', endDate: '2025-03-31')
+generate_balance_sheet(snapshotDate: '2025-03-31')
 ```
 
 Save the quarter's reports. Quarterly-specific assertions:
@@ -156,8 +156,8 @@ 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(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(accountResourceId: <Bonus Liability>, period_start: <FY-start>, period_end: <today>)`. |
+| 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>)`. |
 | 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. |
 

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

@@ -23,8 +23,8 @@
   > The amount filter differs by endpoint: `totalAmount` is accepted on bills and on
   > cashflow-transactions but **rejected on supplier credit notes**, and no `paymentAmount` filter
   > exists anywhere — it is a response field on a payment, not a filter key.
-- **`generate_aged_ap(period_end: <date>)`** — step 5: per-supplier outstanding balance.
-- **`create_bill(...)`** / **`apply_credit_to_bill(...)`** / **`create_supplier_credit_note(...)`** — step 6: post any missing items identified during recon.
+- **`generate_aged_ap(endDate: <date>)`** — step 5: per-supplier outstanding balance.
+- **`create_bill(...)`** / **`apply_credits_to_bill(...)`** / **`create_supplier_credit_note(...)`** — step 6: post any missing items identified during recon.
 
 ### Cross-references
 - Run ad-hoc per major supplier, and at year-end as a mandatory recon for major suppliers (feeds `audit-prep.md` AP confirmations).
@@ -62,7 +62,7 @@ search_bills(
 
 Per bill: `{resourceId, reference, valueDate, currency, originalAmount, paymentRecords, status, dueDate}`. `balanceAmount` is a FILTER key only — the API accepts it in a filter but never returns it on a bill or invoice. Reading it back yields undefined. Derive outstanding instead: `totalAmount - sum(paymentRecords[].transactionAmount) - sum(creditsApplied[].amountApplied)`, and fetch with `view: 'full'` because a lean row omits `paymentRecords` entirely. Keep the Jaz-side bill list for the recon pack.
 
-For an opening-balance recon: also pull the supplier's pre-period balance via `generate_aged_ap(period_end: <period-start - 1 day>)` and filter to this supplier.
+For an opening-balance recon: also pull the supplier's pre-period balance via `generate_aged_ap(endDate: <period-start - 1 day>)` and filter to this supplier.
 
 ## Step 3 — Pull payments
 
@@ -83,7 +83,7 @@ Save. Each credit note may have been applied to one or more bills; the applicati
 ## Step 5 — Compute Jaz-side closing balance
 
 ```
-generate_aged_ap(period_end: '2025-01-31')
+generate_aged_ap(endDate: '2025-01-31')
 ```
 
 Filter to this supplier. Compute: opening balance + new bills (step 2) - payments (step 3) - applied credit notes (step 4) = closing balance per Jaz.
@@ -99,7 +99,7 @@ Practitioner provides the supplier's statement (PDF, email, paper). Per-line-ite
 | 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. |
 | Bill unpaid per Jaz, supplier says paid | Payment recorded against wrong supplier OR bill | Audit `search_payments(filter: {valueDate: {eq: <date>}, totalAmount: {eq: <amount>}})`; identify mis-routing; post correcting journal OR re-issue payment. |
-| Supplier credit note not in Jaz | Missed credit | `create_supplier_credit_note(...)` per supplier statement. Then `apply_credit_to_bill(...)` to the offsetting bill. |
+| Supplier credit note not in Jaz | Missed credit | `create_supplier_credit_note(...)` per supplier statement. Then `apply_credits_to_bill(...)` to the offsetting bill. |
 | Currency mismatch | FX bills with different rates | Confirm Jaz used the right rate per `jaz-api/SKILL.md` rule 25; the supplier statement may use spot rate, Jaz uses recorded rate. Document the FX gap. |
 
 ## Step 7 — Post corrections + verify
@@ -108,7 +108,7 @@ For each missing bill / credit note: post via `create_bill` / `create_supplier_c
 
 After corrections:
 ```
-generate_aged_ap(period_end: '2025-01-31')
+generate_aged_ap(endDate: '2025-01-31')
 ```
 
 Filter to supplier. New closing balance should match the supplier statement closing balance within tolerance (typically zero — pricing rounding on long-running accounts can leave cents).
@@ -131,7 +131,7 @@ Keep, per supplier:
 | Step 2 | Bill count > page limit | Paginate via `offset`. |
 | Step 6 | Currency mismatch on supplier statement | Standard FX handling — supplier records in the supplier's base currency, Jaz records in the org's base currency. Compare in the supplier's currency for the parity check; FX gap goes to FX gain/loss separately. |
 | Step 7 | `create_bill` 422 `valueDate_in_locked_period` | The missing bill belongs to a locked period. Lift lock via `update_account` lockDate, post, re-lock. Surface to practitioner — auditor will see late posting. |
-| Step 7 | `apply_credit_to_bill` 422 `credit_exceeds_balance` | Trying to apply more credit than the bill has remaining. Practitioner judgment — split the credit across multiple bills OR carry forward. |
+| Step 7 | `apply_credits_to_bill` 422 `credit_exceeds_balance` | Trying to apply more credit than the bill has remaining. Practitioner judgment — split the credit across multiple bills OR carry forward. |
 
 ---