AI bookkeeping records credit card repayments as expenses, and month-end reconciliation is always off by a few hundred yuan — in 2026, what balances that gap?

Conclusion first: In 2026, when building AI bookkeeping or a financial assistant, credit card repayments, refunds, and transfers between your own accounts being recorded as expenses is usually not because OCR or large models are not capable enough, but because a funds-direction decision chain is missing. In practice, a more reliable order is: first fix the business-layer account-type matrix and counterparty normalization, then add a layer of manual confirmation above the amount threshold. Conversely, if you stack manual confirmation first, the interruption rate and customer service costs will rise, while direction errors will still keep polluting budgets, reports, and expense reimbursement modules.

I. Why repayments, refunds, and own-account transfers are the three categories most likely to have their direction recorded backwards

Judging whether a transaction is income or expense is essentially not text classification, but funds-flow direction determination. Bank transaction summaries have many forms: auto repayment, credit card repayment-last digits, consumer installment posting, refund, account transfer, cash installment... The same 'repayment' is a funds outflow on the savings card side, and a credit limit restoration on the credit card side. If you only apply plus/minus signs by keywords, one side will be recorded as expense while the other is recorded as income.

Direction is also an upstream field for three layers: classification, budgeting, and reporting. If direction is wrong, categories will be wrong as a consequence, monthly budgets will show 'not much spent but over budget', and reimbursement or tax modules may even count refunds as income. Therefore, in projects, direction accuracy usually deserves attention before classification accuracy.

• Common three categories: credit card/Huabei-type repayments, refunds and returns, and transfers between your own accounts.
• Next two common categories: installment postings, and actual paid amounts after coupon/red packet deductions.
• Counterexample: assigning a negative sign only because the text says 'repayment', or a positive sign only because the text says 'income'; cross-account transactions will almost certainly go wrong.

II. Four-layer breakdown: models only extract, direction is left to rules

Putting direction determination into prompts makes rules unexplainable and impossible to regression test. After layering, the model turns unstructured content into fields, direction is decided by auditable rules, and the interface layer collects user feedback when uncertain.

1. Capability layer: Use OCR and text extraction to turn screenshots, SMS, emails, and statement files into structured fields: time, amount, counterparty, summary, account last digits. Model families such as Tongyi, DeepSeek, GPT, and Claude can all handle this; choose by accuracy and cost, but do not put direction judgment into prompts.
2. Business layer: The direction determination rule engine. The core is the account-type matrix (savings card, credit card, e-wallet, brokerage, cash), counterparty normalization (multiple summary writings for the same merchant mapped to one entity), and combinations of keywords and amount signs. Rules need versioning and rollback.
3. Interface layer: Make 'direction pending confirmation' a one-click interaction, rather than making users go into a detail page and edit field by field; confirmation must be able to write back and record time.
4. Data and risk control: Direction label library, correction feedback loop, monthly reconciliation gate, and operation audit trail; amount thresholds and duplicate transactions are also persisted in this layer.

Each layer watches different metrics: the capability layer watches field completeness rate, the business layer watches rule coverage rate, the interface layer watches confirmation click steps, and the data layer watches whether corrections actually take effect. A common pitfall is mixing the four layers together, so when a problem appears, it is unclear whether extraction is wrong, rules are wrong, or the user's edit did not write back.

III. Delivery context: what to do first under a three-to-four-week timeline

In bookkeeping projects run according to enterprise delivery habits, common constraints are a timeline of only three to four weeks, data sources limited to SMS and screenshots, and a budget that does not support long-term manual labeling. A more reliable approach is: in the first week, focus on organizing the account-type matrix and high-frequency counterparty whitelist, and pause hard keyword matching; in weeks two to three, add manual confirmation above the amount threshold and the reconciliation gate. The result is that the direction error rate drops from the typical range of 8%-15% to an experience range of 2%-5%. The cost is that the first week takes product and operations time for account sorting. If this step is skipped and the model is tuned directly, rework usually happens at acceptance, adding one to two revision rounds.

IV. Fix rules first or stack confirmation first: a set of verifiable comparisons

The two are not opposed; it is a question of order. In experience, the more common combination is rules first and confirmation as fallback, but different business stages have different emphases.

• Route A: fix rules first (account matrix + counterparty normalization + direction label library). Time to impact is typically 1-2 weeks; initial investment is concentrated in product and data organization, with an experience range of several thousand to ten to twenty thousand yuan when converted to in-house labor; long-term manual cost is low and user interruption is small; suitable for scenarios with many sources and monthly reconciliation requirements.
• Route B: add manual confirmation first (a confirmation popup above the amount threshold). Time to impact can be compressed to a few days; initial development cost is low; but the trigger rate is relatively high, with an experience range possibly reaching 20%-40%, and long-term customer service and interruption costs rise; suitable for early versions with a single source and a tight launch timeline.
• Counterexample: neither doing rules nor setting thresholds, but making users confirm every transaction, users usually give up maintaining it within a few days, and the book data becomes worse.

Acceptance criteria should be viewed together: direction determination accuracy (combined measure after rules plus confirmation) has a common experience range of 95%-98%; manual confirmation trigger rate is recommended to be controlled within an experience range of 5%-15%; the number of monthly reconciliation discrepancy entries is controlled within a few per thousand of total entries, and each discrepancy can be traced to a cause. If you only count extraction field accuracy and do not count reconciliation discrepancies, acceptance may pass easily, but users will still feel the books are wrong.

V. Applicable and non-applicable boundaries

This approach suits personal bookkeeping, small and micro merchant transaction categorization, and scenarios requiring monthly budgets and reports, especially when data sources include bank SMS, screenshots, and emails at the same time. Financial books for external reporting and bookkeeping that must strictly follow accounting standards are not suitable for handing direction determination directly to AI; they should still go through professional financial software and retain manual review.

• Suitable: multi-source transaction categorization, monthly reconciliation needs, and users accepting a small amount of confirmation interaction.
• Do not need it: small tools that only display transactions without categorization, with a single source and simple amount structure; adding a rule engine instead increases maintenance cost.
• Use caution: directly using AI determination results for tax filing, auditing, or external reporting; without manual review and audit trail, it is not recommended to launch.
• API and private deployment: In 2026, a common approach is to first run through with APIs, then evaluate private deployment once call volume or data sensitivity rises.

Frequently asked questions

If AI bookkeeping gets the direction wrong, can switching to a larger model solve it?

Switching models mostly only reduces text extraction errors; direction determination still depends on the account-type matrix and counterparty normalization. In experience, fixing business-layer rules first is more cost-effective.

Why does the same credit card repayment have opposite directions in a savings card and a credit card?

On the savings card side it is a funds outflow; on the credit card side it is credit limit restoration. If account type is not included in the determination logic, one side will be recorded as expense while the other is recorded as income.

Will adding manual confirmation disturb users too much?

Trigger it by amount threshold (typical range 50-200 yuan) and make it one click; the trigger rate can fall within an experience range of 5%-15%, which is less trouble than arguing over every transaction during after-the-fact reconciliation.

Which numbers should be watched during launch acceptance?

Look at direction determination accuracy, manual confirmation trigger rate, and monthly reconciliation discrepancy entries together, and require that corrections can flow back and take effect; only then is it qualified.

If a product is troubled by 'the same repayment being recorded in the wrong direction', it is advisable to first spend one week organizing the account-type matrix and high-frequency counterparties, move direction determination from prompts into the rule engine, and then decide the amount threshold for confirmation interaction. If there is only one type of data source and no monthly reconciliation need, there is no rush to add the rule layer; just make field extraction solid first.