The latest articles on DEV Community by 王鹏（圣光） (@_747e6bc6520603eccbroot085414). https://dev.to/_747e6bc6520603eccbroot085414 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4060810%2F3ca874d3-afbe-449d-afdf-b0558b755c64.png https://dev.to/_747e6bc6520603eccbroot085414 en 王鹏（圣光） Mon, 03 Aug 2026 14:05:00 +0000 https://dev.to/_747e6bc6520603eccbroot085414/why-matching-transfers-matters-more-than-importing-csvs-in-finance-software-13d5 https://dev.to/_747e6bc6520603eccbroot085414/why-matching-transfers-matters-more-than-importing-csvs-in-finance-software-13d5 <p>Importing a bank CSV is mostly a parsing problem. Reconciliation is an inference problem.</p> <p>I learned this while combining several open-source finance projects into a local-first workflow for tax preparation. The first prototype could map columns from different statements, but the resulting ledger was still not reliable enough for an accountant.</p> <h2> The transfer problem </h2> <p>Suppose a user moves $2,000 from checking to savings. One export contains -2000; another contains +2000. A naive categorizer records an expense and income even though no economic event occurred.</p> <p>Real exports make the match harder:</p> <ul> <li>the posting dates may differ by several days</li> <li>one account may truncate the memo</li> <li>foreign-currency transfers may include a conversion spread</li> <li>fees may be separate transactions or included in the amount</li> <li>an overlapping export may contain the same row twice</li> </ul> <h2> The pipeline I ended up using </h2> <ol> <li>Normalize source columns without discarding the original row.</li> <li>Build a stable fingerprint for exact and near-duplicate detection.</li> <li>Generate transfer candidates only between accounts the user marks as their own.</li> <li>Score candidates using inverted amount, date distance, currency, memo similarity, and nearby fee rows.</li> <li>Use one-to-one matching so a transaction cannot explain multiple transfers.</li> <li>Auto-accept high-confidence pairs and send the rest to a short review queue.</li> </ol> <p>The confidence boundary matters more than the classifier. Quietly guessing wrong creates clean-looking books with bad numbers. Leaving five uncertain rows visible is much better than hiding them inside hundreds of automatic categorizations.</p> <h2> Privacy boundary </h2> <p>Statement processing runs in the browser or the local desktop app. Raw files and SSNs are not uploaded. The output is a reconciliation package with normalized transactions, detected duplicates, proposed transfer pairs, exceptions, and source references.</p> <p>The app organizes records for an accountant or a later tax workflow; it does not file the return itself.</p> <p>I put a working sample-data demo here: <a href="https://tax.507643.xyz" rel="noopener noreferrer">https://tax.507643.xyz</a></p> <p>The next edge cases I am working through are split transfers, credit-card payments that post over a weekend, and currency conversion where neither side exposes the actual exchange rate.</p> opensource automation webdev productivity