How Tidings works

Tidings turns the transaction alerts your bank already sends into a private finance journal. Nothing is scraped, and no bank credentials are stored. Everything downstream reads from one local store, so the concepts on this page recur on every other page in this section.

The pipeline

1 Your bank emails a transaction alert

2 Forwarder [email protected]

3 Parser amount · merchant · date

4 Categorization your rules first, AI optional

5 Local store SQLite or DynamoDB

every page is a read of this one store — JournalTransactionsSummaryBudgetsInsightsMerchants

Each transaction follows the same path:

1. Your bank emails a transaction alert.
2. Your forwarder sends that email to Tidings.
3. A deterministic, per-bank parser reads the amount, merchant, and date from the email.
4. Your category rules (overrides) are checked first — matching the merchant by exact name, alias, or fuzzy similarity. A confident match applies the category and skips everything else.
5. If you have opted into AI categorization under Settings → Intelligence, the categorizer runs next; otherwise the transaction stays uncategorized.
6. The result is stored locally — SQLite on the self-hosted setup, DynamoDB on the AWS variant.

Every page you see is a different read of that single store.

Two queues that sound alike

The most confusable pair in Tidings is the difference between an email that never became a transaction and a transaction that has no category.

A bank email arrives the deterministic parsers try to read it

no parser could read it

Needs review the raw email is quarantined — no transaction exists yet, and nothing is counted

Recover it: retry after a parser fix, or enter the transaction by hand.

parsed into a transaction

Transaction created a real row in the ledger, counted in your totals

Attention queue on Transactions — holds rows that still need a category confirmed

Decide: pick a category, or confirm the one already there.

• Needs review holds raw emails no parser could read. They are quarantined, not transactions — no transaction exists for them until you recover one. This is where you go when a bank is not yet supported.
• The attention queue on Transactions holds transactions that already exist but still need a category.

One is about emails that failed to parse; the other is about transactions that need a decision. Keeping them apart saves a lot of confusion.

What changes when you edit

Different edits reach different distances. Some rewrite history, some only shape what happens next.

Action	What it changes	Retroactive?
Rename a category	Transactions, overrides, and budget groups everywhere	Yes, always
Add a category rule (override)	New transactions from then on	No
Add an auto-ignore rule	New transactions, unless you choose to apply it to history	No, unless applied
Add a merchant alias	The display name only — nothing stored changes	No stored change

The distinction to hold onto: renaming a category is the one edit that reaches backward through everything you have already recorded. Rules and aliases shape the future or the surface, not the record.

The second way in

Email misses things — a card that sends no alerts, a month before you set up forwarding. Statements are the second ingestion path: you upload a bank PDF and Tidings parses the transactions it missed.

Time

Your instance timezone decides which day and month a transaction belongs to, which is why the boundary matters for month totals. You set it in settings.

Where to go next

• Architecture for the technical deep dive on the pipeline and storage.
• Quickstart to set up your own instance.