Reflect 3 Attempt 01

ERP Finance Expense-Control — Skill Reference

Environment & API

All tasks use the shared ERP finance REST API. Filter records with exact-match query parameters by field name (claim_id, business_id, vendor_id, account, period, bill_id). Paginate with limit and offset. The API is read-only; no create/update/delete operations are needed.

Key endpoints:

1. Expense Claim Close Review (Reimbursement-to-AP)

Claim Classification

For each claim ID in the batch, fetch the claim, its AP bills, and their payments.

CRM-Required Claims

All blocked claims that need expense-case owner cleanup or AP-link remediation are crm_required. In practice this is typically all blocked claims — the distinction between reimbursement-case issues (missing receipts, policy flags) and AP/payment evidence issues (void bills, amount mismatches, missing bills) is preserved in how the claim is categorized, but both types require owner follow-up.

AP Open Balance

Sum the bill amounts for payable claims only, where the bill is valid (not void, amount matches the claim). Do not include paid claims or blocked claims. Report in USD to 2 decimal places.

Batch Status

• blocked — any claim in the batch is blocked.
• open_payables — no blocked claims, but at least one payable claim remains.
• ready_to_close — no blocked claims and no payable claims (all paid).

Reviewed Claim Count

The number of claim IDs in the requested batch (not all claims in the system).

Output Ordering

All claim-ID lists must be sorted ascending by claim ID.

2. Vendor Onboarding Finance-Risk Release

Data Sources

Cross-reference /api/compliance/objects (by business_id) with /api/vendors (by vendor_id from the compliance record). The onboarding batch payload provides the business_ids and an as_of_date.

Per-Business Decision

Hard-Stop Flags

Available flags (alphabetical per business):

Sort each business's flags alphabetically. Return an empty list [] when none apply.

Reportable UBO Counts

Count unique beneficial-owner names whose ownership_pct is ≥ 25%. If the same name appears in multiple UBO entries for the same business, count that name once — deduplicate by name, not by entry. Report as an integer.

Follow-Up Business IDs

All business IDs whose decision is not approve. Sorted ascending.

Overall Release Ready

true only if every listed business has decision approve.

Tax ID Validation

Compare compliance tax_id with vendor tax_id. A mismatch means the tax ID is invalid/untrusted. Non-standard TIN formats (e.g. containing "X") are also a red flag.

3. Prepaid Close Check

Invoice-Level Calculations

For each invoice in the prepaid scope, using the close period (e.g. March 2025):

• Months elapsed through the close period: Count full calendar months from service_start through the close month, inclusive. For a service starting January 1 with a March close, that is 3 months (Jan, Feb, Mar). For a service starting mid-month (e.g. March 15), the March period counts as 1.

• March amortization (single-month): Use monthly_amortization from the API as-is.

• Cumulative amortization through March: monthly_amortization × months_elapsed, capped at original_amount for fully-amortized contracts. Use the API's monthly_amortization value directly for multiplication; do NOT recompute from original_amount ÷ total_months.

• Ending balance: original_amount − cumulative_amortization. When the contract is fully amortized (all months elapsed), ending balance is 0.00.

Data Quality Flags

Account Rollup

Group invoices by account (1250 or 1251). For each account compute:

• selected_invoice_count — number of scoped invoices for that account
• original_amount_total — sum of original_amount
• march_amortization_total — sum of March amortizations
• cumulative_amortization_through_march — sum of cumulative amortizations
• schedule_ending_balance — original_amount_total − cumulative_amortization_through_march
• gl_ending_balance — from /api/prepaids/gl-balances
• variance_amount — schedule_ending_balance − gl_ending_balance
• variance_flag — true if |variance_amount| > variance_threshold_abs (default: 100.00)
• has_default_missing_term_flag — true if ANY invoice in the account has default_missing_term_flag
• account_status:
  • reconciled — variance within threshold AND no default/missing term invoices
  • variance_review — variance exceeds threshold but no default/missing term invoices
  • requires_reconciliation — any invoice has default/missing term issues OR variance is extreme

Output Ordering

• selected_invoice_ids: same order as in prepaid_close_scope.json
• invoice_results: same order as in prepaid_close_scope.json
• default_missing_term_invoice_ids: ascending by invoice ID
• exception_invoice_ids: ascending by invoice ID

All currency amounts in USD to 2 decimal places.

4. Stale AP Snapshot Reconciliation

Approach

The stale CSV snapshot is context only, not the system of record. Reconcile each candidate claim against current API data (claim, bills, payments). The snapshot correction field records what the stale snapshot got wrong.

Snapshot Correction Values

AP Balance by Claim

For each claim, compute the open AP balance as:

Bill amount − sum of cleared payment amounts

Only consider bills that are NOT void. If no valid bill exists for the claim, balance is 0.00. If the only bill has an amount mismatch with the claim, the mismatch takes precedence (the bill should be excluded), and balance is 0.00.

Eligibility

• Eligible: Claim is approved, has a valid matching bill (amount matches, not void), and payment is either in-flight or the claim is settled through a correct paid bill.
• Not ready: All other claims — unapproved, void bill, amount/vendor mismatch, or no bill.

Close Log Required

Set required: true when the batch contains stale/incorrect snapshot rows that need documentation. Include specific close-log IDs from /api/close/logs that reference stale AP exports, legacy imports, or duplicate lines related to the claims in scope. Use an empty list if no specific log entries are relevant.

Batch Status

• ready_to_send — all claims are eligible, no corrections needed.
• needs_ap_refresh — some snapshot rows are stale/incorrect, but claims themselves are ready once AP data is refreshed.
• blocked — one or more claims have blocking issues (unapproved, void bill, no bill, amount mismatch).

Output Ordering

All claim-ID lists sorted ascending by claim ID.

5. AP Payment Release After Account-Change Events

Data Sources

For each business_id in the batch, fetch /api/compliance/objects and the linked /api/vendors record. Cross-reference with the account-change ticket (requested_bank_last4, change_type, priority, requested_release_amount_usd).

Review date is the batch as_of_date.

Decision Logic

Flag Lists (all sorted ascending by business_id)

General Conventions

Currency

All monetary values in USD, reported to 2 decimal places (cents). Use standard rounding (half-up).

Sorting

• Claim-ID lists: ascending by claim ID (lexicographic string order).
• Business-ID lists: ascending by business_id (lexicographic string order).
• Hard-stop flags within a business: alphabetical.
• Invoice lists: same order as the scope input file.

Source Precedence

1. Current API data is the system of record.
2. Stale snapshots and batch payloads are context only.
3. When API data contradicts a snapshot/payload, the API wins.

Common Pitfalls

• Partial-month contracts: For prepaid amortization, count the start month as month 1 even if the service starts mid-month. Do not prorate the monthly amount.
• Rounding in fully-amortized contracts: Cap cumulative amortization at original_amount so ending balance is exactly 0.00, not 0.01.
• Multiple bills per claim: A claim may have several bills. Classify based on the bill that matches the claim amount. Ignore stale/wrong-amount bills for balance and eligibility purposes, but they may still need a snapshot correction.
• License expiry vs as_of_date: A license expiring on the as_of_date is NOT expired. Only licenses with expiry dates strictly before the as_of_date are expired.
• UBO deduplication: Count unique names, not unique entries. The same person listed multiple times at different ownership percentages counts as one UBO if any of their entries meets the 25% threshold.
• Tax ID validation: Check both format validity (no "X" or placeholder patterns) AND cross-system consistency (compliance vs vendor).
• Void bills: Always exclude void bills from AP balance calculations and eligibility determinations.
• Payment status processing: A payment that is processing is NOT cleared. The bill amount remains in the open AP balance.