jaz-clio 5.55.3 → 5.55.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/assets/skills/api/SKILL.md +1 -1
- package/assets/skills/cli/SKILL.md +1 -1
- package/assets/skills/conversion/SKILL.md +1 -1
- package/assets/skills/jaz-kit/SKILL.md +1 -1
- package/assets/skills/jaz-pseudo-sql/SKILL.md +1 -1
- package/assets/skills/jobs/SKILL.md +1 -1
- package/assets/skills/jobs/references/bank-recon.md +3 -3
- package/assets/skills/jobs/references/credit-control.md +2 -2
- package/assets/skills/jobs/references/fa-review.md +1 -1
- package/assets/skills/jobs/references/gst-vat-filing.md +1 -1
- package/assets/skills/jobs/references/month-end-close.md +4 -4
- package/assets/skills/jobs/references/payment-run.md +3 -3
- package/assets/skills/jobs/references/supplier-recon.md +1 -1
- package/assets/skills/transaction-recipes/SKILL.md +1 -1
- package/package.json +1 -1
|
@@ -7,7 +7,7 @@
|
|
|
7
7
|
### Platform tools — discovery + auto-match
|
|
8
8
|
- **`list_bank_accounts()`** — step 1: pull all bank-type CoA accounts (per `jaz-api/SKILL.md` rule 18: GET `/bank-accounts` returns flat array `[{...}]`, NOT the standard paginated `{ data, totalElements, totalPages }` shape — normalize before consuming).
|
|
9
9
|
- **`search_accounts(filter: {accountType: {eq: 'Bank Accounts'}})`** — step 1 alternative: same data via standard CoA-search envelope if downstream wants pagination.
|
|
10
|
-
- **`search_bank_records(accountResourceId: <id>, status: 'UNRECONCILED', startDate: <from>, endDate: <to>, limit: 200,
|
|
10
|
+
- **`search_bank_records(accountResourceId: <id>, status: 'UNRECONCILED', startDate: <from>, endDate: <to>, limit: 200, sortBy: 'valueDate', sortOrder: 'ASC')`** — step 2: per-account work queue.
|
|
11
11
|
- **`search_bank_records(accountResourceId: <id>, status: 'POSSIBLE_DUPLICATE')`** — step 3: handle dups FIRST or you'll double-create reconciling them.
|
|
12
12
|
- **`view_auto_reconciliation(bankStatementEntryResourceIds: [<id>, ...], recommendationType: 'MAGIC_MATCH' | 'RECOMMENDATIONS' | 'MAGIC_RECONCILE_WITH_CASH_TRANSFER' | 'MAGIC_RECONCILE_WITH_BANK_RULE' | 'MAGIC_QUICK_RECONCILE' | 'MAGIC_RECONCILE_WITH_CASH_IN_OUT', bankAccountResourceId?: <id>, autoCommitMaxAmount?: <number>)`** — step 4: READ-ONLY auto-match suggestions. **Pick the group, not the whole world:** `RECOMMENDATIONS` returns every type except `MAGIC_MATCH` in one ranked call and is the cheaper request; `MAGIC_MATCH` scans open transactions across the account and is asked for on its own. The four specific values narrow to one type. There is no value that returns everything at once, so a two-sided sweep is two calls. `recommendationType` is a REQUEST selector only: `RECOMMENDATIONS` never comes back as a suggestion's own `recommendationType`, which is always a concrete type. **`bankStatementEntryResourceIds` is REQUIRED — this endpoint is per-entry and there is no account-wide mode.** Source the ids from `search_bank_records` with status `UNRECONCILED`. Pass `bankAccountResourceId` too: it is merged into each suggestion's `execute` args for `reconcile_magic_match`. Returns **execution-ready `suggestions[]`** — each carries `recommendedTool`, `execute` (ready-to-pass args), `confidenceTier`, and `autoCommitEligible`. This is the entry point for the auto-match decision gate (step 4a). `MAGIC_RECONCILE_WITH_CASH_IN_OUT` returns Learned-Predictions. Does NOT write. NOTE: cost tracks the entries you pass — batch large backlogs. On a 500 it degrades to `{degraded:true}`; fall back to the cascade matcher (see error table).
|
|
13
13
|
- **`search_cashflow_transactions(filter: {organizationAccountResourceId: <bank-id>, totalAmount: {eq: <amt>}, valueDate: {between: [<-3d>, <+3d>]}})`** — step 5 manual match: search book-side transactions for the same amount within ±3 day window.
|
|
@@ -69,7 +69,7 @@ search_bank_records(
|
|
|
69
69
|
startDate: '2025-01-01',
|
|
70
70
|
endDate: '2025-01-31',
|
|
71
71
|
limit: 200,
|
|
72
|
-
|
|
72
|
+
sortBy: 'valueDate', sortOrder: 'ASC'
|
|
73
73
|
)
|
|
74
74
|
```
|
|
75
75
|
|
|
@@ -143,7 +143,7 @@ search_cashflow_transactions(
|
|
|
143
143
|
totalAmount: { eq: 2500.00 },
|
|
144
144
|
valueDate: { between: ['2025-01-08', '2025-01-22'] }
|
|
145
145
|
},
|
|
146
|
-
|
|
146
|
+
sortBy: 'valueDate', sortOrder: 'DESC',
|
|
147
147
|
limit: 20
|
|
148
148
|
)
|
|
149
149
|
```
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
### Platform tools
|
|
8
8
|
- **`generate_aged_ar(period_end: <date>)`** — step 1: AR aging report with bucket breakdown.
|
|
9
|
-
- **`search_invoices(filter: {status: {eq: 'UNPAID'}, dueDate: {lt: <date>}, contactResourceId: <customer>},
|
|
9
|
+
- **`search_invoices(filter: {status: {eq: 'UNPAID'}, dueDate: {lt: <date>}, contactResourceId: <customer>}, sortBy: 'dueDate', sortOrder: 'ASC', limit: 200)`** — step 2: per-customer overdue detail. Paginate.
|
|
10
10
|
- **`get_contact(resourceId: <customer id>)`** — step 2: pull contact info (email, phone, primary contact).
|
|
11
11
|
- **`get_contact_signals(resourceId: <id>, btType: 'SALE')`** — step 3: pull cadence + outlier signals + outstanding balance for the customer. Mid-7 endpoint.
|
|
12
12
|
- **`apply_credit_to_invoice(...)`** / **`create_customer_credit_note(...)`** — step 6: write-off path A for stage-3 specific impairment.
|
|
@@ -44,7 +44,7 @@ search_invoices(
|
|
|
44
44
|
contactResourceId: <customer id>,
|
|
45
45
|
dueDate: {lt: '2025-01-31'}
|
|
46
46
|
},
|
|
47
|
-
|
|
47
|
+
sortBy: 'dueDate', sortOrder: 'ASC',
|
|
48
48
|
limit: 200
|
|
49
49
|
)
|
|
50
50
|
```
|
|
@@ -33,7 +33,7 @@ Walk steps 1-8 below. (Local CLI: `clio jobs fa-review` prints the same phased c
|
|
|
33
33
|
## Step 1 — Enumerate FAs
|
|
34
34
|
|
|
35
35
|
```
|
|
36
|
-
search_fixed_assets(filter: {status: {in: ['ACTIVE', 'DISPOSED', 'WRITTEN_OFF']}}, limit: 200,
|
|
36
|
+
search_fixed_assets(filter: {status: {in: ['ACTIVE', 'DISPOSED', 'WRITTEN_OFF']}}, limit: 200, sortBy: 'purchaseDate', sortOrder: 'ASC')
|
|
37
37
|
```
|
|
38
38
|
|
|
39
39
|
Paginate via offset. For year-end review: include DISPOSED and WRITTEN_OFF (disposed during the year are part of the recon).
|
|
@@ -66,7 +66,7 @@ Halt if any expected profile is missing — surface to practitioner with create
|
|
|
66
66
|
## Step 3 — Output-tax detail review
|
|
67
67
|
|
|
68
68
|
```
|
|
69
|
-
search_invoices(filter: {valueDate: {between: ['2025-01-01', '2025-03-31']}, status: {in: ['UNPAID', 'PARTIALLY_PAID', 'PAID']}}, limit: 200,
|
|
69
|
+
search_invoices(filter: {valueDate: {between: ['2025-01-01', '2025-03-31']}, status: {in: ['UNPAID', 'PARTIALLY_PAID', 'PAID']}}, limit: 200, sortBy: 'valueDate', sortOrder: 'ASC')
|
|
70
70
|
```
|
|
71
71
|
|
|
72
72
|
Paginate via offset if `totalElements > 200`. For each invoice:
|
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
## Tools, recipes, calculators this job uses
|
|
6
6
|
|
|
7
7
|
### Platform tools — pre-close gates
|
|
8
|
-
- **`search_invoices(filter: {valueDate: {between: [<period-start>, <period-end>]}},
|
|
8
|
+
- **`search_invoices(filter: {valueDate: {between: [<period-start>, <period-end>]}}, sortBy: 'valueDate', sortOrder: 'ASC', limit: 200)`** — step 1: confirm sales invoices entered. Paginate via `offset`.
|
|
9
9
|
- **`search_bills(filter: {valueDate: {between: [<period-start>, <period-end>]}}, ...)`** — step 2: confirm purchase bills entered.
|
|
10
10
|
- **`search_bank_records(accountResourceId: <id>, status: 'UNRECONCILED', startDate: <from>, endDate: <to>)`** — step 3: pull unreconciled bank statement entries per account.
|
|
11
11
|
- **`generate_aged_ar(period_end: <date>)` / `generate_aged_ap(period_end: <date>)`** — steps 4-5: aging reports tied to TB AR / AP balances.
|
|
@@ -56,7 +56,7 @@ This playbook runs 5 phases for the period: pre-close gates → accruals & adjus
|
|
|
56
56
|
### Step 1 — Verify sales invoices entered
|
|
57
57
|
|
|
58
58
|
```
|
|
59
|
-
search_invoices(filter: {valueDate: {between: ['2025-01-01', '2025-01-31']}},
|
|
59
|
+
search_invoices(filter: {valueDate: {between: ['2025-01-01', '2025-01-31']}}, sortBy: 'valueDate', sortOrder: 'ASC', limit: 200)
|
|
60
60
|
```
|
|
61
61
|
|
|
62
62
|
Compare count + sum against POS / sales register. Missing invoices = understated revenue. Per `jaz-api/SKILL.md` rule 38, paginate via `offset` if `totalElements > 200`.
|
|
@@ -64,7 +64,7 @@ Compare count + sum against POS / sales register. Missing invoices = understated
|
|
|
64
64
|
### Step 2 — Verify bills entered (most common SMB gap)
|
|
65
65
|
|
|
66
66
|
```
|
|
67
|
-
search_bills(filter: {valueDate: {between: ['2025-01-01', '2025-01-31']}},
|
|
67
|
+
search_bills(filter: {valueDate: {between: ['2025-01-01', '2025-01-31']}}, sortBy: 'valueDate', sortOrder: 'ASC', limit: 200)
|
|
68
68
|
```
|
|
69
69
|
|
|
70
70
|
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.
|
|
@@ -74,7 +74,7 @@ Cross-reference against email + supplier portals + physical mail. Late bills = m
|
|
|
74
74
|
For each bank account:
|
|
75
75
|
|
|
76
76
|
1. If you don't already have the account's resourceId: `list_bank_accounts()`, match by `name + currency`, confirm with the user.
|
|
77
|
-
2. `search_bank_records(accountResourceId: <bank account resourceId>, status: 'UNRECONCILED', startDate: '2025-01-01', endDate: '2025-01-31', limit: 200,
|
|
77
|
+
2. `search_bank_records(accountResourceId: <bank account resourceId>, status: 'UNRECONCILED', startDate: '2025-01-01', endDate: '2025-01-31', limit: 200, sortBy: 'valueDate', sortOrder: 'ASC')`.
|
|
78
78
|
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.
|
|
79
79
|
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_*`.
|
|
80
80
|
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,7 +5,7 @@
|
|
|
5
5
|
## Tools, recipes, calculators this job uses
|
|
6
6
|
|
|
7
7
|
### Platform tools (jaz-api)
|
|
8
|
-
- **`search_bills(filter: {status: {eq: 'UNPAID'}, balanceAmount: {gt: 0}, dueDate: {lte: <cutoff>}},
|
|
8
|
+
- **`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`).
|
|
9
9
|
- **`generate_aged_ap(period_end: <cutoff>)`** — used in step 3: total-AP cross-check; flag bills in 60d+ aging buckets.
|
|
10
10
|
- **`generate_bank_balance_summary(period_end: <cutoff>)`** — used in step 5: confirm cash availability before approving the batch.
|
|
11
11
|
- **`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).
|
|
@@ -49,7 +49,7 @@ search_bills(
|
|
|
49
49
|
balanceAmount: {gt: 0},
|
|
50
50
|
dueDate: {lte: '2025-02-28'}
|
|
51
51
|
},
|
|
52
|
-
|
|
52
|
+
sortBy: 'dueDate', sortOrder: 'ASC',
|
|
53
53
|
limit: 200
|
|
54
54
|
)
|
|
55
55
|
```
|
|
@@ -151,7 +151,7 @@ Assert: per-account balance reduced by `sum(paymentAmount per accountResourceId)
|
|
|
151
151
|
|
|
152
152
|
## Variations
|
|
153
153
|
|
|
154
|
-
- **Priority-based payment ordering:** `
|
|
154
|
+
- **Priority-based payment ordering:** `sortBy: 'dueDate', sortOrder: 'ASC'` covers chronological. For overdue-first there is no sort field — `daysOverdue` is not sortable and the API answers `422 sort.sortBy[0] must be one of [...]`, naming the set (measured 2026-09-07). Sort by `dueDate` ASC, which puts the most overdue first, or compute the age per row after fetching. For supplier-strategic, ask the user which suppliers are priority and process those first.
|
|
155
155
|
- **Multi-currency runs:** Split the run by currency. SGD bills → SGD bank; USD bills → USD bank or SWIFT-routed. The actual bank disbursement is handled outside Jaz (via the bank's portal); Jaz records the payment after it clears.
|
|
156
156
|
- **Approval workflow (multi-signatory SMBs):** Build the batch in step 5, get out-of-band approval, then execute step 6 only after sign-off. Do NOT post payments before the actual bank transfer is initiated — Jaz payments are not "payment instructions", they record completed payments.
|
|
157
157
|
- **Early-payment discounts:** If supplier offers `2% 10 Net 30`, computing the equivalent annualized return is `(2% / 98%) × (365 / 20) ≈ 37.2%`. Take it when cash allows. Apply the discount as: pay `transactionAmount = (derived outstanding) × 0.98`, then post a separate journal Dr Bank Charges/Discount Income for the 2% saved (cleaner than partial payment of the original bill).
|
|
@@ -55,7 +55,7 @@ Pull `paymentTerms`, `bankAccountNumber`, `taxId`, `paymentMethod` for narrative
|
|
|
55
55
|
```
|
|
56
56
|
search_bills(
|
|
57
57
|
filter: {contact: {resourceId: {eq: <supplier id>}}, valueDate: {between: ['2025-01-01', '2025-01-31']}},
|
|
58
|
-
|
|
58
|
+
sortBy: 'valueDate', sortOrder: 'ASC',
|
|
59
59
|
limit: 200
|
|
60
60
|
)
|
|
61
61
|
```
|