statement-source-onboarding

Onboard bank and platform statement sources into finance-tracker import and relation scanning.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/ssttkkl/finance-tracker --skill statement-source-onboarding-ssttkkl
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: statement-source-onboarding
Source: https://github.com/ssttkkl/finance-tracker/tree/main/.agents/skills/statement-source-onboarding
Command: npx skills add https://github.com/ssttkkl/finance-tracker --skill statement-source-onboarding-ssttkkl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding a new bank, wallet, or platform bill export to finance-tracker often causes mis-booked accounts, missed refund pairs, and false transfer matches. This Skill provides a proven workflow for onboarding statement sources so rows import as correct formal facts and participate correctly in relation scanning. ## Core Features & Use Cases - Taxonomy bucket method: Partition real bills by source-native fields (e.g. Alipay status × direction, WeChat status × type) into a bucket table before writing any scan rules, avoiding global keyword soup. - Account semantics guardrails: Fix which account each transaction books to (withdrawals, money-market redemptions, credit repayments) before tuning scan rules. - Phase-scoped scan rules: Assign hard-key refunds to Phase A, payment mirrors to Phase B, transfers to Phase C, and bank refunds to Phase D, with bucket-scoped predicates. - Use Case: When adding a new bank's CSV export, build the bucket table from real multi-year statements, define per-bucket import transforms and scan roles, then calibrate with a fresh SQLite database and relations check until pending counts stabilize. ## Quick Start Ask the assistant to onboard a new bank statement export for finance-tracker using the statement source onboarding workflow, starting from real sample bills.

Frequently Asked Questions about statement-source-onboarding

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new bank statement source to finance-tracker?

Start from real bill samples, partition them into taxonomy buckets using source-native fields like status and direction, then define per-bucket import transforms and scan roles. Calibrate with a fresh database, run relations check, and iterate only on the target buckets.

How do I fix wrong account mapping for withdrawals in bill imports?

Book the source account, not the destination: a wallet withdrawal to a bank card must debit the wallet, with the destination card kept only as evidence in the payload. Fix the convert and mapping layer first, never patch it with import-time relations.

Why does relation scanning produce false transfer pairs?

False pairs usually come from global keyword rules like matching any text containing transfer or refund. The fix is a taxonomy gate: label legs from native bucket cells first, exclude P2P and red-packet rows, then run fine matching only on gated candidates.

Does the import process write refund or transfer relations directly?

No. Import writes only formal facts with inline source_payload and is idempotent on source_type and record_id. All refund_offset, payment_mirror, and transfer_pair relations are produced later by the one-shot relations check across Phases A through D.

When should a refund matcher go in Phase A versus Phase D?

Phase A is for sources with hard keys such as order IDs or dual-row exports, implemented as pure source-specific matchers. Phase D handles bank-side refunds without hard keys, preferring diamond chains through platform mirrors and falling back to open-leg candidates.