Backfill Tiller with a bank CSV: check signs, balances and duplicate risk

Start with the history Tiller already has

You need to know what's already in the sheet before choosing what to import. Fill the latest available transactions, filter your Transactions sheet to one account, and write down the missing period. Compare its boundary rows with the bank's export, because a date range alone can be misleading if only part of a day reached the sheet. Before changing either file, keep an untouched bank CSV and a copy of your spreadsheet.

Tiller's Console CSV import guide, dated 24 July 2026 and checked on 18 October 2026, supports adding history to an automated account, filling an outage and adding data to a manually tracked account. Its duplicate-prevention advice is to exclude transactions already available in Tiller. Use a native bank CSV when it covers the dates you need; there is no reason to convert a PDF merely to get the same rows.

Keep an account alias, currency, source filename and requested dates beside your working file. A separate batch per account makes sign checking and any later whole-import deletion easier to follow, even though Tiller can detect multiple accounts in a file. The statement coverage checker helps compare document periods with the period you need, but it doesn't establish that every transaction within those periods is present.

Check a payment and a receipt before changing signs

A CSV can contain perfectly readable numbers pointing in the wrong direction. Tiller's supported amount formats include these three layouts. Check actual transactions against the statement rather than assuming that a column called Credit always means what you expect.

For a single-account file whose polarity is reversed, Tiller documents Advanced Settings → Credits/Debits reversed on the mapping screen. This flips positive and negative amounts; it isn't available for a multi-account import. If you already reversed signs in your working CSV, reversing them again during import would undo that change. Check a known purchase, a payment and any refund against the statement, especially for a card account.

Tiller already accepts the layouts above, so a separate conversion step is optional. If you do need to reshape the columns, the debit and credit converter can help. For delimiter and date-format problems, there's CSV format repair, but confirm the source convention first. Neither tool can decide what an ambiguous date meant at the bank.

Tiller's current limitations say every imported row needs a Date value and recommend MM/DD/YYYY. Because a missing date can cause an import to fail without an error, resolve blank dates before uploading. Remove non-transaction headers or totals from a working copy too, keeping a record of those exclusions. If Finish appears stuck, inspect Import History and the sheet before trying another upload so an uncertain outcome doesn't become a repeated batch. The guide mentions a “target sheet” in troubleshooting, but its numbered Console steps select an account, not a sheet.

Add Import Tag before the new rows fill

The importer guide says Import Tag and Source only populate newly filled rows, not rows already in the sheet. That's why you need those columns in place before importing. If Import Tag is absent, Tiller says to insert a column at the far right and put that exact header in row 1; add Source too if it's missing. For older rows without those values, review the date ranges and transaction details instead.

In the Console, open Accounts → Import CSV, choose the file and destination account, and map its columns. Before Finish, review the account and signs. Tiller supplies the generated Import Tag; you don't need to invent a value in the bank CSV. Record it with your original filename, row count, date range and separate incoming and outgoing totals for comparison with the rows that arrive.

How those rows arrive depends on the fill method. The guide says Excel and older Google Sheets on Sidebar Fills need Tiller Money Feeds to fill the imported data; Google Sheets on Direct Fills fills automatically. Compare the rows with your batch record, keeping any missing or unexplained rows on a review list. The import message alone isn't enough to declare success.

Three transactions can become six rows

This fictional USD checking account has $500.00 immediately before 8 September 2026. Assume the following three posted transactions are all activity from 8 through 10 September, with a fictional closing balance of $1,591.75. The sample uses US dates and a decimal point. It is not a bank export or evidence of a tested Tiller import.

Date,Description,Amount
09/08/2026,PAYROLL,1200.00
09/09/2026,GROCERY,-63.25
09/10/2026,INTERNET,-45.00

The file contains $1,200.00 in and $108.25 out, a net increase of $1,091.75. Now suppose you import those rows during an outage, categorize them, and the feed later supplies the same three transactions. The worksheet below represents the resulting review, not another file to upload. Load it as comma-separated data on a separate blank sheet so it occupies A1:H7. Parse column A consistently as US dates and column C as numbers, not text.

Date,Description,Amount,Account,Currency,Source,Import Tag,Decision
09/08/2026,PAYROLL,1200.00,CHK-01,USD,Example CSV,EXAMPLE-BATCH,Review
09/09/2026,GROCERY,-63.25,CHK-01,USD,Example CSV,EXAMPLE-BATCH,Review
09/10/2026,INTERNET,-45.00,CHK-01,USD,Example CSV,EXAMPLE-BATCH,Review
09/08/2026,PAYROLL,1200.00,CHK-01,USD,Example feed,,Review
09/09/2026,GROCERY,-63.25,CHK-01,USD,Example feed,,Review
09/10/2026,INTERNET,-45.00,CHK-01,USD,Example feed,,Review

Source labels and the tag above are illustrative, not guaranteed Tiller field values. Keep your actual Source and Import Tag values unchanged in the real review. With all six rows counted, receipts become $2,400.00 and spending becomes $216.50. Applying that duplicated net movement to the $500.00 opening gives $2,683.50, which is $1,091.75 too high. Those are worksheet calculations, not predictions of Tiller's Balances tab.

The duplicate finder can compare supplied files, or you can use the formula below for this small worksheet. Neither can see your live Tiller account. A same-date, same-amount match is only a candidate: two real purchases can share those fields, while a feed date that differs from the bank CSV can hide a match.

Keep the decision separate from the matching formula

The matching formula compares date, amount, account and currency, leaving descriptions and sources available for your review. Put Matching rows in I1 and the formula in I2, then fill it down through I7. It includes the current row, so all six sample rows return 2, not 1. Google documents the multiple-criteria behavior in COUNTIFS.

=COUNTIFS($A$2:$A$7,A2,$C$2:$C$7,C2,$D$2:$D$7,D2,$E$2:$E$7,E2)

In this fictional case, comparison with the source confirms three duplicate pairs, so keep the categorized CSV copies by changing H2:H4 to Keep and H5:H7 to Exclude. Those are review decisions, not commands that delete anything in Tiller. An Import Tag alone isn't a reason to make that choice.

The formulas below use Google's documented SUM, SUMIFS and COUNTIFS functions. Enter the formula after each colon into the named cell, K2 through K8. These sums don't filter by account or currency, so keep each totals worksheet to one account and currency. The fixed ranges are for this six-row example only; expand every range together for a larger review. The opening and closing balances must cover the same interval as the retained transactions.

K2: =SUM(C2:C7)
K3: =SUMIFS(C2:C7,H2:H7,"Keep")
K4: =SUMIFS(C2:C7,H2:H7,"Keep",C2:C7,">0")
K5: =-SUMIFS(C2:C7,H2:H7,"Keep",C2:C7,"<0")
K6: =COUNTIFS(H2:H7,"Review")
K7: =500+K3
K8: =K7-1591.75

Before the decisions, K6 is 6 and the retained totals are zero, so those partial totals aren't ready to report. Every row must contain exactly Keep, Exclude or Review: K6 counts Review but won't catch blank or misspelled decisions. Confirm three retained rows and three exclusions against the originals. A zero balance difference is useful arithmetic, not proof that all descriptions, categories or rows are right. This example supplies no independent running-balance evidence.

Deleting spreadsheet rows is not deleting the import

Tiller's outage cleanup workflow recommends keeping the CSV copies when they are already categorized, removing the confirmed automated duplicates from the spreadsheet, then deleting the corresponding CSV import from the Console database. These actions affect different places.

After backing up the sheet and filling the latest data, filter one account and inspect the overlapping dates. The documented filter uses Source values such as Yodlee or Plaid together with a blank Import Tag to identify the automated side. That narrows the review; it doesn't make every visible row a duplicate. Remove only confirmed extra copies, preserving the useful category and other edits in the retained rows.

To remove a CSV batch from the database, the guide gives Accounts → the arrow beside Import CSV → Import History → the matching import's trash icon. There's no partial delete: this removes the entire import across every account included in it, so check its tag, filename, count, date range and accounts before deleting. If only some rows have arrived through the feed, deleting the whole batch could lose the only database copy of the rest. In that mixed case, preserve the files and ask Tiller support how to handle it rather than blindly deleting the batch.

Clearing only spreadsheet duplicates leaves the imported copies in the database, which Tiller warns can produce duplicates in future spreadsheets. Clearing only the Console import leaves the current spreadsheet duplicates untouched. Recheck the retained sheet rows and batch record afterward so you can account for both places.

Balances and budget categories are separate work

A transaction backfill is not a balance-history backfill. Tiller's Foundation Template overview, dated 22 May 2026, distinguishes Transactions from Balances, which shows current linked-account balances, and Balance History, which records balances when a refresh is performed. The importer guide explicitly says CSV transaction imports do not update account balances. Adding an opening-balance transaction just to make that tab move is not a fix.

For a manually tracked account, follow Tiller's manual balance instructions, dated 22 June 2026, separately, using an actual balance and its date. For a Console-managed manual account, the documented update is the account's pencil icon, balance date and balance, then Update Balance. Tiller says that manual-account feature isn't intended for automatically updated accounts. Don't replace an unknown historical balance with zero or treat our calculated $1,591.75 as a bank-confirmed value.

If you're coming from YNAB, categories need separate attention too. Tiller's YNAB-to-Tiller guide, dated 8 May 2025, separates the budget CSV, used to prepare the Categories sheet, from the register CSV, used for Transactions. It describes a Google Sheets workflow using the Tiller Community Solutions add-on. That's a different route from the Console bank-CSV import above, not a reason to run both on the same history. A transaction import alone doesn't perform the separate category and budget preparation in that guide.

What we checked

We opened the four linked Tiller help pages and Google's SUM, SUMIFS and COUNTIFS references on 18 October 2026. The Tiller dates quoted above are the dates displayed beside their bylines. We parsed both synthetic CSVs and checked the formula-equivalent matching, review counts, signed totals and balance arithmetic with a Python script using Decimal. We did not run the formulas in Google Sheets or Excel, upload a file to Tiller, test its account connections or verify a real statement. The menu and deletion behavior above is documented by Tiller, not firsthand product testing.