Tax Workflow
Use this skill when the user asks to:
- review card, bank, wallet, or payment-service exports for
確定申告 - decide which transactions can be treated as business expenses
- map transactions to Japanese account titles
- import selected expenses into MoneyForward
- automate MoneyForward manual entry from CSV or similar exports
Inputs To Gather
Before doing any posting work, confirm or infer:
- source file path and target year
- accounting target, usually MoneyForward
- user-specific account-title policy
- whether browser automation is allowed
- whether browser session reuse is allowed
If the user has an explicit bookkeeping policy, follow it and note that it is a user rule rather than a default tax judgment.
Core Principles
- Source categories are hints, not tax truth.
- Keep every posted row traceable back to the source export.
- Prefer deterministic matching on
date + merchant/remark + amount + account text. - Never trust a single fast verification pass if the UI is asynchronous.
- Never retry failed rows blindly.
Classification Workflow
-
Normalize the source data.
- Inspect encoding, headers, duplicated columns, currencies, and date range.
- Filter to the target year.
- Preserve source row IDs if available.
-
Build candidate sets.
- Split rows into
clear include,clear exclude, andmanual review. - Use deterministic rules first: merchant, category, currency, date, memo, amount pattern.
- Treat ambiguous rows as manual review rather than forcing a classification.
- Split rows into
-
Confirm account mapping.
- Default expense entry pattern for personally paid business expenses is:
借方 = expense account貸方 = 事業主借
- Common mappings:
- cafe/workspace:
雑費 - telecom/SIM:
通信費 - transport:
旅費交通費 - lodging: do not assume; confirm the user's policy
- cafe/workspace:
- Default expense entry pattern for personally paid business expenses is:
-
Verify tax-sensitive claims.
- For legal or tax classification questions, prefer official NTA guidance and primary documentation.
- If the user wants a nonstandard treatment, follow their instruction for bookkeeping work but distinguish it from general tax guidance.
MoneyForward Automation Workflow
Prefer this order:
- Use an isolated Playwright-controlled Chrome profile.
- Let the user sign in manually in that isolated browser.
- Inspect the actual MoneyForward form fields and select values before bulk posting.
- Submit one stable accounting pattern at a time.
Avoid:
- reusing encrypted browser state unless explicitly approved and necessary
- depending on the user's live Chrome profile by default
- relying on visual clicks when direct form fields can be identified safely
Verification Workflow
After posting rows:
- Search the journal list using merchant or remark.
- Match on:
- date
- amount
- merchant or remark
- expected account text
- Record the MoneyForward transaction number for each matched row.
Do not assume success from:
- form reset
- HTTP 200
- absence of an error banner
If verification is inconsistent:
- run a second search pass
- then run a count-based audit by source row
- only retry rows that remain genuinely missing
Reconciliation And Cleanup
If retries created duplicates:
- Determine the intended count from the source export.
- Search the MoneyForward journal list by merchant.
- Identify duplicates by exact row details and transaction number.
- Delete only the surplus rows.
- Re-audit until the MoneyForward count matches the source count.
Use transaction numbers for deletion decisions. Do not dedupe by text similarity alone.
Outputs
When the task finishes, provide:
- filtered or normalized source file paths, if created
- imported count
- skipped count
- manual-review count
- duplicate cleanup summary, if any
- list of unresolved rows requiring user judgment
Notes
- Keep the main skill procedural and reusable.
- Put one-off merchant heuristics or session-specific examples in reference files if this skill grows.