# Task Group 005 Fewshot Attempt 03

> Solve PanofyBench task_group_005 ERP, AP, prepaid close, vendor onboarding, and account-change release tasks by using the shared JSON API and returning schema-exact JSON outputs.

- Skill: `prism-shadow/task-group-005-fewshot-attempt-03` (Agent Skill)
- Install (CLI): `npx skillmds@latest add prism-shadow/task-group-005-fewshot-attempt-03`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/task-group-005-fewshot-attempt-03/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: prism-shadow (https://skillmd.com/u/prism-shadow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prism-shadow/task-group-005-fewshot-attempt-03

---


# Task Group 005 ERP Solver

Use this skill when a task asks for finance/AP close, prepaid reconciliation, vendor onboarding release control, or account-change payment release decisions from the task_group_005 shared API.

## API workflow

- Use the API base URL from the prompt or runner. Local variants observed include `<environment_base_url>`; in this environment the same API may be served on another loopback port.
- First call `/endpoints`. The API advertises exact-match query parameters by field name plus `limit` and `offset`.
- Prefer current API records over local snapshots or source review statuses. Local CSV/JSON payloads define scope and output shape; they are not the system of record.
- Common endpoints: `/api/claims`, `/api/ap/bills`, `/api/ap/payments`, `/api/ap/aging`, `/api/close/logs`, `/api/vendors`, `/api/compliance/objects`, `/api/prepaids/invoices`, `/api/prepaids/gl-balances`. Non-`/api` aliases may also exist.
- Return only JSON matching the local `answer_template.json`. Preserve required top-level key order when the template specifies it. Sort ID lists by the template rule, usually ascending ID, except prepaid invoice result lists often preserve payload order.

## Claim and AP close rules

For reimbursement/AP batch tasks, join each scoped claim to current AP bills and payments.

- A payable/open reimbursement needs a current approved claim and a non-void AP bill linked to that claim whose amount, currency, and vendor evidence match the claim. `approved` or `scheduled` AP bill statuses can be open/payable.
- A paid claim needs a matching AP bill for the claim amount and a cleared payment for that bill amount. Do not treat scheduled or processing payments as cleared.
- Compute open AP balance from valid current AP bills minus cleared payments only. Ignore void bills, stale snapshot rows, and AP rows whose amount/vendor/account evidence does not fit the claim.
- Block claims with unapproved claim status, missing AP link, void-only AP evidence, amount/vendor mismatch, draft/invalid bills, or unresolved receipt/support/policy issues that prevent AP release.
- Keep reimbursement-case cleanup separate from AP/payment evidence issues when the output has separate blocked/CRM fields.
- Overall close status: `blocked` if any scoped claim is blocked; otherwise `open_payables` if valid unpaid AP remains; otherwise `ready_to_close`.

For stale AP snapshot tasks:

- Treat the snapshot as historical context. Reconcile every candidate against current claims, bills, payments, aging, and close logs.
- Correction flags map to current evidence:
  - `mark_in_flight_payment`: valid current bill has a non-cleared in-flight payment.
  - `replace_with_matched_paid_bill`: stale row points to the wrong bill/status but a current matched paid bill and cleared payment exist.
  - `exclude_amount_or_vendor_mismatch`: current AP evidence is linked but amount/vendor does not match the claim.
  - `ignore_void_bill`: linked AP bill is void and should not contribute balance.
  - `block_unapproved_claim`: claim is not currently approved/releasable.
  - `current_snapshot_ok`: snapshot agrees with current valid evidence.
- Set `close_log_required.required` when AP refresh or close remediation evidence is needed; include relevant AP close-log IDs sorted ascending.
- Use `needs_ap_refresh` when current evidence supports some release/cleanup but stale rows require AP refresh or close-log action; use `ready_to_send` only when all candidates are currently releasable without refresh; reserve `blocked` for unresolved release blockers.

## Prepaid close rules

Use scoped prepaid invoice IDs only and reconcile only requested accounts/period/entity.

- Pull selected records from `/api/prepaids/invoices` and GL ending balances from `/api/prepaids/gl-balances`.
- Use the invoice's `monthly_amortization` for straight-line schedules. Count service months from `service_start` through the close month when the invoice is active in that month; mid-month starts still count as that month when represented by the source schedule.
- For each invoice:
  - `march_amortization` or period amortization is the monthly amount if active in the close month, else `0.00`.
  - cumulative amortization through the close month is monthly amount times included service months, capped/rounded so ending balance is not negative except for cent-level source rounding.
  - ending balance is `original_amount - cumulative_amortization`, rounded to two decimals.
- `default_missing_term_flag` is true for missing/defaulted term evidence such as `missing_contract_dates`.
- `exception_flag` is true when invoice `data_quality_flags` is non-empty or other source quality exceptions apply. Keep this separate from account-level variance.
- Account rollups sum selected invoices by account. `variance_amount = schedule_ending_balance - gl_ending_balance`; flag variance when absolute variance exceeds the payload threshold.
- Use `requires_reconciliation` for material variances or missing-term/default flags, `variance_review` for review-only exceptions/immaterial variance, and `reconciled` only when schedule, GL, and invoice evidence are clean.

## Vendor onboarding release rules

For finance-risk onboarding, query compliance by `business_id` and linked vendor by `vendor_id`.

- Reportable UBO count is the number of unique UBO names with `ownership_pct >= 25`; do not double-count duplicate names.
- Hard-stop flags:
  - `bank_closed`: `bank_account_status == "closed"`.
  - `bank_name_mismatch`: `bank_account_status == "name_mismatch"`.
  - `confirmed_pep`: `pep_status == "confirmed_pep"`.
  - `expired_license`: `license_expiry` is before the task as-of date.
  - `missing_required_documents`: `missing_fields` is non-empty.
  - `sanctions_confirmed`: sanctions check is confirmed/positive.
  - `screening_not_run`: sanctions or PEP screening is `not_run`.
  - `shell_company_suspected`: source boolean is true.
  - `vendor_on_hold`: linked vendor status is `on_hold`.
- Sort each business's hard-stop flags alphabetically by enum value.
- Decision: `approve` only when release evidence is clean. Use `awaiting_information` for missing documents or not-run screening without a more severe stop. Use `escalate` for confirmed PEP, sanctions, shell suspicion, closed/mismatched bank, vendor hold, expired license with other hard stops, or other high-risk blocks.
- `follow_up_business_ids` are all non-approved businesses. `overall_release_ready` is true only when every scoped business is approved.

## Account-change payment release rules

Use the local account-change payload for target IDs, ticket bank last4, requested amounts, and review date; use API compliance/vendor records for current evidence.

- `target_business_ids` and all ID lists follow the template order, usually ascending `business_id`.
- `bank_mismatch_ids` include only compliance `bank_account_status == "name_mismatch"` unless the template says to include closed banks.
- `invalid_tax_ids` include businesses where compliance tax ID is malformed or does not match the linked vendor tax ID.
- `expired_license_ids` compare `license_expiry` to the task `as_of_date`; expired means strictly before that date.
- `risk_score_override_flags` include `risk_score >= 70`.
- `review_queue_ids` are all businesses that are not released.
- Decision: `release` only when bank, vendor status, requested bank last4, tax, license, sanctions/PEP, and risk evidence are clean. Use `hold` for remediable operational blocks such as name mismatch, closed bank, expired license, missing documents, not-run screening, or risk override when no severe contradiction exists. Use `escalate` for invalid tax, vendor hold, confirmed PEP/sanctions, shell suspicion, or combined severe evidence.

## Output discipline

- Use numeric dollars with two decimals unless the template explicitly asks for cents.
- Do not add explanatory text, comments, or unrequested keys.
- Do not copy current `review_status` or source `status` fields blindly; derive release/close posture from all required evidence.
- When multiple current records exist for the same scoped ID, choose the record that matches the business object: exact claim/business ID, amount, vendor, currency, and current payment state.