jaz-cli 2.6.0 → 2.8.0

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

@@ -0,0 +1,234 @@
+# Bank Reconciliation Catch-Up
+
+Clear unreconciled bank statement entries by matching them to existing transactions, creating missing ones, and flagging duplicates. This is the single most impactful thing you can do for book accuracy — a clean bank recon means cash is right, and cash being right means everything else has a fighting chance.
+
+**CLI:** `jaz jobs bank-recon [--account "DBS Current"] [--period 2025-01] [--json]`
+
+---
+
+## Phase 1: Identify Bank Accounts
+
+List all bank accounts in the org. If `--account` is specified, filter to that one. Otherwise, reconcile all of them.
+
+### Step 1: List bank accounts
+
+```
+GET /api/v1/bank-accounts?limit=100&offset=0
+```
+
+Or via CoA search (more reliable — gives you the resourceId directly):
+
+```
+POST /api/v1/chart-of-accounts/search
+{
+  "filter": { "accountType": { "eq": "Bank Accounts" } },
+  "sort": { "sortBy": ["name"], "order": "ASC" }
+}
+```
+
+**What you get:** A list of bank-type CoA accounts with `resourceId`, `name`, `currencyCode`. You need the `resourceId` for every subsequent step.
+
+---
+
+## Phase 2: Pull Unreconciled Items
+
+For each bank account, pull all unreconciled bank records. This is your working list.
+
+### Step 2: Search unreconciled bank records
+
+```
+POST /api/v1/bank-records/{accountResourceId}/search
+{
+  "filter": {
+    "status": { "eq": "UNRECONCILED" },
+    "valueDate": { "between": ["2025-01-01", "2025-01-31"] }
+  },
+  "sort": { "sortBy": ["valueDate"], "order": "ASC" },
+  "limit": 1000
+}
+```
+
+**Omit the `valueDate` filter** if you want to see ALL unreconciled items regardless of date. For a catch-up, you usually want everything.
+
+**What to check:**
+- Count of unreconciled items — this is your work queue
+- Any items older than 60 days are red flags (investigate immediately)
+- `netAmount` positive = cash-in, negative = cash-out
+- `extContactName` and `description` are your best clues for matching
+
+### Step 3: Check for possible duplicates
+
+```
+POST /api/v1/bank-records/{accountResourceId}/search
+{
+  "filter": { "status": { "eq": "POSSIBLE_DUPLICATE" } },
+  "sort": { "sortBy": ["valueDate"], "order": "ASC" },
+  "limit": 1000
+}
+```
+
+**Handle duplicates first.** If two bank feed entries have the same date, amount, and description, the system flags them as `POSSIBLE_DUPLICATE`. Review and archive the genuine duplicates before proceeding — otherwise you'll create double entries trying to reconcile them.
+
+---
+
+## Phase 3: Categorize and Resolve
+
+Work through each unreconciled item. There are four resolution paths.
+
+### Path A: Match to existing transaction
+
+The bank record matches an invoice payment, bill payment, or journal already in the books. This is the ideal case — the transaction exists, it just hasn't been linked to the bank record.
+
+**How to find the match:** Search cashflow transactions for the same amount and approximate date:
+
+```
+POST /api/v1/cashflow-transactions/search
+{
+  "filter": {
+    "organizationAccountResourceId": { "eq": "<bank-account-uuid>" },
+    "totalAmount": { "eq": 2500.00 },
+    "valueDate": { "between": ["2025-01-10", "2025-01-20"] }
+  },
+  "sort": { "sortBy": ["valueDate"], "order": "DESC" },
+  "limit": 20
+}
+```
+
+**Tip:** Widen the date range by a few days — bank processing delays mean the book date and bank date often differ by 1-3 business days.
+
+### Path B: Create missing transaction from attachment
+
+The bank record represents a real transaction, but nothing has been entered in the books yet. If you have the receipt, invoice, or bill document, use Jaz Magic to create the transaction automatically.
+
+```
+POST /api/v1/magic/createBusinessTransactionFromAttachment
+Content-Type: multipart/form-data
+
+Fields:
+  - sourceFile: <PDF or JPG of the invoice/receipt>
+  - businessTransactionType: "BILL" (for expenses) or "INVOICE" (for income)
+  - sourceType: "FILE"
+```
+
+Jaz Magic handles OCR, line item extraction, contact matching, and CoA mapping. It creates a draft transaction that you review and post.
+
+**When you don't have a document:** Create the transaction manually using the appropriate endpoint (invoice, bill, cash-in, cash-out).
+
+### Path C: Create cash journal for bank fees/charges
+
+Bank fees, interest charges, service charges, and similar items don't have a corresponding invoice or bill. Record them as cash-out journals.
+
+```
+POST /api/v1/cash-out-journals
+{
+  "saveAsDraft": false,
+  "reference": "BANK-FEE-JAN25-001",
+  "valueDate": "2025-01-15",
+  "accountResourceId": "<bank-account-uuid>",
+  "journalEntries": [
+    { "accountResourceId": "<bank-fees-expense-uuid>", "amount": 25.00, "type": "DEBIT", "name": "Monthly service charge — Jan 2025" }
+  ]
+}
+```
+
+For bank interest earned (cash-in):
+
+```
+POST /api/v1/cash-in-journals
+{
+  "saveAsDraft": false,
+  "reference": "BANK-INT-JAN25-001",
+  "valueDate": "2025-01-31",
+  "accountResourceId": "<bank-account-uuid>",
+  "journalEntries": [
+    { "accountResourceId": "<interest-income-uuid>", "amount": 12.50, "type": "CREDIT", "name": "Interest earned — Jan 2025" }
+  ]
+}
+```
+
+### Path D: Flag for investigation
+
+Some items don't have an obvious match or explanation. Flag these for the business owner or finance manager to investigate. Common causes:
+- Personal transactions through the business account
+- Refunds or chargebacks
+- Intercompany transfers not yet recorded
+- Errors in the bank feed (rare but happens)
+
+---
+
+## Phase 4: Verification
+
+After resolving all items, verify the reconciliation is clean.
+
+### Step 4: Re-check unreconciled count
+
+```
+POST /api/v1/bank-records/{accountResourceId}/search
+{
+  "filter": { "status": { "eq": "UNRECONCILED" } },
+  "sort": { "sortBy": ["valueDate"], "order": "ASC" },
+  "limit": 1
+}
+```
+
+**Target:** Zero unreconciled items for the period, or only genuine timing differences (outstanding cheques, deposits in transit that will clear next period).
+
+### Step 5: Bank balance summary
+
+```
+POST /api/v1/generate-reports/bank-balance-summary
+{ "primarySnapshotDate": "2025-01-31" }
+```
+
+**What to check:**
+- Book balance per Jaz should match the bank statement closing balance
+- Any difference should equal the sum of known timing items
+- Zero unreconciled difference = clean recon
+
+### Step 6: Bank reconciliation summary report
+
+```
+POST /api/v1/generate-reports/bank-reconciliation-summary
+{ "primarySnapshotDate": "2025-01-31" }
+```
+
+This gives you the formal reconciliation statement showing: opening balance + cash in - cash out = closing balance, with the reconciling items listed.
+
+---
+
+## Bank Recon Checklist (Quick Reference)
+
+| # | Step | Phase | What |
+|---|------|-------|------|
+| 1 | List bank accounts | Identify | Get all bank-type CoA accounts |
+| 2 | Pull unreconciled items | Pull | Search by status = UNRECONCILED |
+| 3 | Check duplicates | Pull | Review POSSIBLE_DUPLICATE items |
+| A | Match to existing | Resolve | Link to existing invoice/bill/journal |
+| B | Create from attachment | Resolve | Use Jaz Magic for documents |
+| C | Create cash journal | Resolve | Bank fees, interest, charges |
+| D | Flag for investigation | Resolve | Unexplained items |
+| 4 | Re-check count | Verify | Should be zero (or timing items only) |
+| 5 | Bank balance summary | Verify | Book balance = bank statement |
+| 6 | Reconciliation report | Verify | Formal reconciliation statement |
+
+---
+
+## Tips for SMBs
+
+**Do this weekly, not monthly.** A weekly 15-minute recon is far easier than a monthly 3-hour catch-up. Monday morning is ideal — reconcile the prior week's bank activity before the new week starts.
+
+**Set up bank rules for recurring items.** If you pay the same rent, subscription, or utility every month, create a bank rule to auto-categorize it. This eliminates the most repetitive part of recon.
+
+```
+POST /api/v1/bank-rules
+```
+
+**Use bank feeds if available.** Aspire and Airwallex direct feeds auto-import bank records daily. This eliminates the CSV import step entirely.
+
+**Don't let it pile up.** The longer a bank record sits unreconciled, the harder it is to figure out what it was. After 90 days, you're essentially doing forensic accounting. Stay current.
+
+**Common SMB bank fee accounts:**
+- Bank Charges / Bank Fees (operating expense)
+- Interest Expense (for overdraft/loan interest)
+- Interest Income (for savings/deposit interest)
+- Foreign Exchange Gain/Loss (for FX conversion fees)

package/assets/skills/jobs/references/building-blocks.md

@@ -0,0 +1,135 @@
+# Building Blocks for Accounting Jobs
+
+Shared concepts that all jobs rely on. Read this first.
+
+---
+
+## Accounting Periods
+
+Jaz uses a **financial year** (FY) that may not match the calendar year. The org's FY start date determines period boundaries.
+
+**Period formats used in jobs:**
+- Month: `YYYY-MM` (e.g., `2025-01` = January 2025)
+- Quarter: `YYYY-QN` (e.g., `2025-Q1` = Jan–Mar 2025 for calendar-year orgs)
+- Year: `YYYY` (e.g., `2025` = full FY 2025)
+
+**Period boundaries matter for:**
+- Search filters (`valueDate between`) — determines which transactions are "in period"
+- Report snapshots (`startDate`, `endDate`, `primarySnapshotDate`) — determines what the reports cover
+- Lock dates — determines what can no longer be edited
+
+---
+
+## Lock Dates
+
+Lock dates prevent backdated entries. Two levels:
+
+| Level | What it locks | When to set |
+|-------|--------------|-------------|
+| **Org-wide** | All transactions before this date | After month/quarter/year-end close |
+| **Per-account** | Specific CoA account locked before date | For bank accounts after recon, or controlled accounts |
+
+**Setting lock dates via API:**
+- Org lock date: managed through organization settings
+- Per-account lock date: `lockDate` field on CoA account
+
+**Best practice for SMBs:**
+- Set org lock date after completing each month-end close
+- Move it forward each month: Jan close → lock to 2025-01-31, Feb close → lock to 2025-02-28
+- Only move lock date forward, never backward (unless correcting errors — requires admin)
+
+---
+
+## Period Verification Pattern
+
+Every job ends with a verification phase. The universal pattern:
+
+### 1. Trial Balance Check
+```
+POST /generate-reports/trial-balance
+{ "startDate": "YYYY-MM-01", "endDate": "YYYY-MM-DD" }
+```
+- Total debits MUST equal total credits
+- No unexpected account balances (e.g., negative cash, negative inventory)
+- Compare to prior period — flag significant variances
+
+### 2. P&L Review
+```
+POST /generate-reports/profit-and-loss
+{ "primarySnapshotDate": "YYYY-MM-DD", "secondarySnapshotDate": "YYYY-MM-01" }
+```
+- Revenue and expense trends should make sense
+- One-off entries (accruals, adjustments) should be explainable
+
+### 3. Balance Sheet Review
+```
+POST /generate-reports/balance-sheet
+{ "primarySnapshotDate": "YYYY-MM-DD" }
+```
+- Assets = Liabilities + Equity (always, by definition)
+- Bank balances match bank statements
+- AR/AP aging ties to balance sheet control accounts
+
+### 4. Bank Balance Reconciliation
+```
+POST /generate-reports/bank-balance-summary
+{ "primarySnapshotDate": "YYYY-MM-DD" }
+```
+- Book balance per Jaz should match bank statement closing balance
+- Differences = timing items (outstanding cheques, deposits in transit)
+
+---
+
+## Scheduler Verification
+
+Many month-end steps are automated via schedulers. Before closing, verify:
+
+1. **Schedulers fired** — Check that recurring journals were created for the period
+   - `POST /journals/search` with capsule filter + valueDate in period
+2. **Amounts correct** — Fixed schedulers should produce consistent amounts
+3. **No duplicates** — If you manually posted a journal AND the scheduler fired, you'll double-count
+
+**Common issue for SMBs:** Scheduler was set up mid-period or end date already passed. Always check before assuming automation handled it.
+
+---
+
+## Capsule Conventions for Jobs
+
+Jobs reference capsules from transaction recipes. Standard capsule types:
+
+| Capsule Type | Used By |
+|-------------|---------|
+| Prepaid Expenses | Prepaid amortization steps |
+| Deferred Revenue | Revenue recognition steps |
+| Accrued Expenses | Accrued expense steps |
+| Loan Repayment | Loan interest accrual steps |
+| Lease Accounting | IFRS 16 lease steps |
+| Depreciation | Non-standard depreciation steps |
+| FX Revaluation | Period-end FX revaluation |
+| ECL Provision | Bad debt provision steps |
+| Employee Benefits | Leave and bonus accrual steps |
+
+**Verification shortcut:** Group the General Ledger by capsule to see the complete lifecycle of each multi-step workflow in one view.
+
+---
+
+## Report API Quick Reference
+
+Jobs frequently generate reports. The key endpoints and their required fields:
+
+| Report | Endpoint | Required Fields |
+|--------|----------|----------------|
+| Trial Balance | `POST /generate-reports/trial-balance` | `startDate`, `endDate` |
+| P&L | `POST /generate-reports/profit-and-loss` | `primarySnapshotDate`, `secondarySnapshotDate` |
+| Balance Sheet | `POST /generate-reports/balance-sheet` | `primarySnapshotDate` |
+| General Ledger | `POST /generate-reports/general-ledger` | `startDate`, `endDate`, `groupBy: "ACCOUNT"` |
+| AR Aging | `POST /generate-reports/ar-report` | `endDate` |
+| AP Aging | `POST /generate-reports/ap-report` | `endDate` |
+| Cash Balance | `POST /generate-reports/cash-balance` | `reportDate` |
+| Cashflow | `POST /generate-reports/cashflow` | `primaryStartDate`, `primaryEndDate` |
+| Bank Balance | `POST /generate-reports/bank-balance-summary` | `primarySnapshotDate` |
+| Tax Ledger | `POST /generate-reports/vat-ledger` | `startDate`, `endDate` |
+| FA Register | `POST /generate-reports/fixed-assets-summary` | (check endpoint) |
+| Equity Movement | `POST /generate-reports/equity-movement` | `primarySnapshotStartDate`, `primarySnapshotEndDate` |
+
+**Data exports** (Excel/CSV) use `/data-exports/` with the same report names but simpler field names (e.g., P&L export uses `startDate`/`endDate` instead of snapshot dates).

package/assets/skills/jobs/references/credit-control.md

@@ -0,0 +1,273 @@
+# Credit Control / AR Chase
+
+Systematically chase overdue customer invoices, assess collection risk, and manage bad debt exposure. This is not just "send reminders" — it's a structured process to protect your cash flow and recognize when receivables are impaired.
+
+**CLI:** `jaz jobs credit-control [--overdue-days 30] [--json]`
+
+---
+
+## Phase 1: Generate the AR Aging
+
+The aging report is your starting point. Everything flows from this.
+
+### Step 1: Generate AR aging report
+
+```
+POST /api/v1/generate-reports/ar-report
+{ "endDate": "2025-02-28" }
+```
+
+**What you get:** All outstanding customer invoices grouped by aging bucket (current, 1-30 days, 31-60 days, 61-90 days, 91-120 days, 120+ days), with totals per customer and grand totals.
+
+### Step 2: Export for working paper (optional)
+
+```
+POST /api/v1/data-exports/ar-report
+{ "endDate": "2025-02-28" }
+```
+
+---
+
+## Phase 2: Prioritize
+
+### Step 3: Filter by overdue threshold
+
+If `--overdue-days` is specified (e.g., 30), focus on invoices overdue by at least that many days. Otherwise, review all overdue items.
+
+**Priority classification:**
+
+| Priority | Overdue | Action |
+|----------|---------|--------|
+| **Critical** | 90+ days | Escalate to management, consider legal, assess bad debt |
+| **High** | 60-90 days | Direct phone call, formal demand letter |
+| **Medium** | 30-60 days | Follow-up email with statement of account |
+| **Low** | 1-30 days | Gentle reminder, may be processing delay |
+| **Current** | Not yet due | No action needed — monitor only |
+
+### Step 4: Group by customer, sort by largest balance
+
+From the AR aging data, rank customers by total overdue amount (descending). The 80/20 rule applies — a handful of customers typically account for most of your overdue AR.
+
+---
+
+## Phase 3: Detailed Customer Review
+
+For each overdue customer (starting with the largest balances), pull the full picture.
+
+### Step 5: List outstanding invoices for a customer
+
+```
+POST /api/v1/invoices/search
+{
+  "filter": {
+    "contactResourceId": { "eq": "<customer-uuid>" },
+    "status": { "eq": "POSTED" },
+    "balanceAmount": { "gt": 0 }
+  },
+  "sort": { "sortBy": ["dueDate"], "order": "ASC" },
+  "limit": 100
+}
+```
+
+**What to check per invoice:**
+- `dueDate` — How overdue is it?
+- `balanceAmount` — How much is still owed? (Could be partially paid)
+- `reference` — The invoice number for follow-up correspondence
+- `totalAmount` vs `balanceAmount` — Has the customer been making partial payments?
+
+### Step 6: Check for unapplied credit notes
+
+Before chasing, verify there are no unapplied customer credit notes that should reduce the balance:
+
+```
+POST /api/v1/customer-credit-notes/search
+{
+  "filter": {
+    "contactResourceId": { "eq": "<customer-uuid>" },
+    "status": { "eq": "POSTED" }
+  },
+  "sort": { "sortBy": ["valueDate"], "order": "DESC" },
+  "limit": 50
+}
+```
+
+If there are unapplied credit notes, apply them before chasing:
+
+```
+POST /api/v1/invoices/{invoiceResourceId}/credits
+{
+  "credits": [
+    { "creditNoteResourceId": "<credit-note-uuid>", "amountApplied": 500.00 }
+  ]
+}
+```
+
+### Step 7: Generate statement of account
+
+```
+POST /api/v1/statement-of-account-export
+```
+
+The statement of account is what you send to the customer — it shows all invoices, payments, and the running balance. Attach this to follow-up communications.
+
+---
+
+## Phase 4: Follow-Up Priority List
+
+### Step 8: Build the chase list
+
+For each overdue customer, document:
+
+| Customer | Total Overdue | Oldest Invoice | Days Overdue | Priority | Action |
+|----------|--------------|----------------|--------------|----------|--------|
+| Acme Corp | $45,000 | INV-1023 | 95 | Critical | Phone + demand letter |
+| Beta Ltd | $12,500 | INV-1089 | 62 | High | Phone call |
+| Gamma Inc | $3,200 | INV-1134 | 35 | Medium | Email reminder |
+
+**Escalation process (typical SMB):**
+
+1. **Day 1-7 overdue:** Automated or gentle email reminder with invoice attached
+2. **Day 14 overdue:** Second reminder, direct email to AP contact
+3. **Day 30 overdue:** Phone call to AP contact, request payment commitment date
+4. **Day 45 overdue:** Escalate to customer's management, send statement of account
+5. **Day 60 overdue:** Formal demand letter, consider suspending future sales on credit
+6. **Day 90 overdue:** Final demand, engage collections agency or legal counsel
+7. **Day 120+ overdue:** Write off if uncollectable (see Phase 5)
+
+---
+
+## Phase 5: Bad Debt Assessment
+
+**Conditional:** Only if there are material amounts in the 90+ day aging bucket.
+
+### Step 9: Assess bad debt risk
+
+For invoices that appear uncollectable, evaluate using the ECL (Expected Credit Loss) model:
+
+**Calculator:** `jaz calc ecl`
+
+```bash
+jaz calc ecl --current 100000 --30d 50000 --60d 20000 --90d 10000 --120d 5000 --rates 0.5,2,5,10,50
+```
+
+This produces the provision matrix — the estimated total bad debt exposure based on aging buckets and historical loss rates.
+
+**Recipe:** `bad-debt-provision` — see `transaction-recipes/references/bad-debt-provision.md` for the full ECL provision pattern.
+
+### Step 10: Record bad debt write-off (if uncollectable)
+
+When a specific invoice is confirmed uncollectable (customer bankrupt, dissolved, or dispute resolution failed), write it off:
+
+**Option A: Customer credit note + write-off journal**
+
+Create a customer credit note to clear the invoice balance:
+
+```
+POST /api/v1/customer-credit-notes
+{
+  "contactResourceId": "<customer-uuid>",
+  "saveAsDraft": false,
+  "reference": "CN-BADDEBT-001",
+  "valueDate": "2025-02-28",
+  "lineItems": [{
+    "name": "Bad debt write-off — INV-1023",
+    "unitPrice": 45000.00,
+    "quantity": 1,
+    "accountResourceId": "<bad-debt-expense-uuid>"
+  }]
+}
+```
+
+Then apply the credit note to the invoice:
+
+```
+POST /api/v1/invoices/{invoiceResourceId}/credits
+{
+  "credits": [
+    { "creditNoteResourceId": "<credit-note-uuid>", "amountApplied": 45000.00 }
+  ]
+}
+```
+
+**Option B: Use DEBT_WRITE_OFF payment method**
+
+Record as a payment using the special write-off method:
+
+```
+POST /api/v1/invoices/{invoiceResourceId}/payments
+{
+  "payments": [{
+    "paymentAmount": 45000.00,
+    "transactionAmount": 45000.00,
+    "accountResourceId": "<bad-debt-expense-uuid>",
+    "paymentMethod": "DEBT_WRITE_OFF",
+    "reference": "WRITEOFF-INV-1023",
+    "valueDate": "2025-02-28"
+  }]
+}
+```
+
+**Accounting effect:** DR Bad Debt Expense, CR Accounts Receivable — removes the receivable from the books and recognizes the expense.
+
+---
+
+## Phase 6: Verification
+
+### Step 11: Re-run AR aging after actions
+
+```
+POST /api/v1/generate-reports/ar-report
+{ "endDate": "2025-02-28" }
+```
+
+**What to check:**
+- Credit notes have reduced the correct invoice balances
+- Written-off invoices no longer appear in the aging
+- Total AR ties to the Accounts Receivable balance on the trial balance
+
+### Step 12: Review trial balance impact
+
+```
+POST /api/v1/generate-reports/trial-balance
+{ "startDate": "2025-02-01", "endDate": "2025-02-28" }
+```
+
+**What to check:**
+- Accounts Receivable balance reflects all collections, credit notes, and write-offs
+- Bad Debt Expense (if write-offs were made) shows the correct amount
+- Allowance for Doubtful Debts (if using provision method) reflects the ECL calculation
+
+---
+
+## Credit Control Checklist (Quick Reference)
+
+| # | Step | Phase | Conditional |
+|---|------|-------|-------------|
+| 1 | Generate AR aging | Assess | Always |
+| 2 | Export working paper | Assess | Optional |
+| 3 | Filter by overdue threshold | Prioritize | If --overdue-days specified |
+| 4 | Group by customer | Prioritize | Always |
+| 5 | List outstanding invoices | Review | Always |
+| 6 | Check unapplied credit notes | Review | Always |
+| 7 | Generate statement of account | Review | Always |
+| 8 | Build chase list | Follow-up | Always |
+| 9 | Assess bad debt (ECL) | Bad debt | If material 90d+ balances |
+| 10 | Record write-off | Bad debt | If confirmed uncollectable |
+| 11 | Re-run AR aging | Verify | Always |
+| 12 | Review trial balance | Verify | Always |
+
+---
+
+## Tips for SMBs
+
+**Typical credit terms:** Net 30 is standard in Singapore. Some industries use Net 60 or Net 14. Whatever your terms, enforce them consistently — if you let one customer pay at 60 when terms are 30, everyone will.
+
+**Prevention is cheaper than collection.** Before extending credit to a new customer, do a basic credit check (ACRA business profile for SG companies, $5.50). Set a credit limit and stick to it.
+
+**The phone is more effective than email.** After 30 days, email follow-ups have diminishing returns. A 5-minute phone call to the AP department resolves more overdue invoices than 10 emails.
+
+**Document everything.** Keep records of all follow-up attempts (dates, who you spoke to, commitments made). If it goes to legal, you need an evidence trail.
+
+**When to involve legal:** If the amount exceeds $20,000 and the customer is unresponsive after 90 days, consider a letter of demand from a lawyer ($300-500). For amounts under $10,000, the Small Claims Tribunal (SG) is a cost-effective option.
+
+**Bad debt tax deduction (SG):** Bad debts written off are deductible for income tax purposes if you can prove the debt is genuinely irrecoverable and reasonable steps were taken to collect. Keep documentation.