Changelog — Shoshita

1.4.0 — 10 September 2026

Fixed the Generic CSV (auto-detect) importer reading the wrong column as the description. On several bank layouts it picked the transaction date, or the column holding the words Debit and Credit, so transactions imported showing a date or the word “Debit” where the merchant name should be. Chase credit-card, Chase checking, Capital One, RBC, BMO, Tangerine and Wealthsimple Cash exports were all affected.
Fixed card payments being counted as income by the Generic CSV importer. On a credit-card account, anything in the Credit column — a payment to the card, or a refund — was recorded as Income, which raised both the income figure and the monthly surplus by the full amount. A payment to a card is money moved to reduce a balance, not money earned. Those rows are now recorded as Credit Card Payment, which is counted as neither income nor spending. The importer knows to do this because it now reads whether you registered the account as a credit card.
Fixed amounts being skipped silently by the Generic CSV importer. An amount written as (45.20) for a negative, or carrying a currency symbol or code such as US$45.20 or 45.20 USD, failed to import, and nothing said so. The row simply was not there afterwards.
Fixed RBC exports importing nothing at all through the Generic CSV importer. RBC names its amount columns CAD$ and USD$, which the importer did not recognise, so the file produced no transactions and no error message.
A failed import now names the columns it could not find, instead of only reporting that no transactions were found. If your file has title or date-range lines above the row of column names, it now tells you to remove them.
Fixed dates written as plain digits importing as 1 January 1970. Where a bank writes a date as 20260814 rather than 2026-08-14, every transaction in the file was dated 1970 and the import still reported success. Unlike the items above, this one affected every import format, not only Generic CSV.

If you imported a statement with Generic CSV before 1.4.0, those transactions are still wrong in your data folder. These fixes apply when a file is imported. They do not revisit transactions that are already saved, and updating to 1.4.0 does not correct them.

Importing the same file again does not replace the faulty transactions. Shoshita skips an incoming transaction only when it matches one already saved on date, amount, description, account and type. Because these fixes change the description and the type, a corrected transaction no longer matches its faulty original, so both are kept and the amounts are then counted twice. To correct the data:

Open the transaction table and select the statement month you imported into.
Delete the transactions that came from that import.
Import the file again, choosing the same format you chose the first time. Different formats read the same file differently — importing an RBC file as RBC joins its two description fields, while Generic CSV takes only the first — so switching format leaves you with both copies again.

The clearest signs that you are affected are a card payment listed as Income, a transaction whose description is a date, and any transaction dated January 1970. If a month’s surplus has looked higher than your statement, the first of those is the likely cause.

Still present in 1.4.0. Two of the faults above have equivalents in the bank-specific importers, and this release does not change those. Only the Generic CSV importer knows whether an account is a credit card, so if you import a credit-card statement by choosing your bank by name, the only thing stopping a payment being recorded as Income is auto-categorization. Whether that catches it depends on how your bank writes the description: “payment - thank you” and “payment from - ***” are caught by the built-in rules, while “capital one autopay pymt”, “autopay pymt” and “payment thank you” without the hyphen are not. A refund is never caught, on any bank, because none of the built-in keywords describe one, so a refund on a card is always recorded as Income. Check the Income figure for any credit-card account you import by bank name, and recategorize any payment or refund you find there as Credit Card Payment. Separately, importing a Tangerine export by choosing Tangerine puts the word Debit or Credit in the description; importing the same file as Generic CSV reads it correctly.

A known limitation. On a credit-card statement a refund arrives in the same column as a payment to the card, and Shoshita records both as Credit Card Payment. That is right for a payment. A refund should reduce that month’s spending, and it does not. Correct those by hand if you need your category totals to match your statement.

1.3.1 — 5 September 2026

Fixed the built-in web server listening on every network interface instead of on this computer only. Shoshita runs a small local server to draw its own window, and because that server accepted connections from any address, another machine on the same network could reach Shoshita's unlock screen. Your vault contents were not exposed: the encryption key and every decrypted record belong to the browser session that unlocked them, so a connection from anywhere else met the passphrase prompt and nothing behind it. The server now accepts connections only from the computer it runs on.

1.3.0 — 5 September 2026

The free trial is now 30 days.
Your vault is unlocked with a generated five-word passphrase instead of a six-digit PIN. This is a security change rather than a cosmetic one: five words drawn from a 7,776-word list is a far larger keyspace than one million PINs, and that is what makes the 600,000 PBKDF2 iterations worth having.
Changing your passphrase now removes the backups that were locked with the old one, keeping a single safety copy taken just before the change. That copy still opens with your old passphrase.
Corrected three inaccurate statements in the bundled documentation: the cipher is AES-128, not AES-256; the app makes one network request when you activate rather than none at all; and your passphrase is verified by decrypting a stored check phrase, not by comparing a hash.
Factory Reset now clears the in-memory session as well as the files. In earlier versions the app kept serving data from memory after a reset, and the next save could write it back to disk.
Factory Reset now deletes your automatic backups too. Previously they were left behind and still opened with the old passphrase.
Lock Screen now clears the decrypted session from memory. Previously it only returned you to the passphrase screen.

1.2.0 — 31 August 2026

The first public release.

A free 14-day trial with every feature unlocked. No account and no card.
If the trial runs out before you buy, you can still enter your PIN and export every transaction, rule and budget to plain CSV files.
Fixed several problems in license activation, including a misleading “device limit reached” message shown for a mistyped key, and a double-click that could consume a second activation.
Corrected the in-app instructions for finding your license key. It is in your customer portal, not in the purchase email.

Shoshita does not update itself. New releases are listed here, and you install one by downloading the current version from the download page and running it over your existing install. Your data and your license are untouched.