Tables: Store Your Data Inside BankSync

A table is a dataset stored inside your BankSync workspace: a name, an icon, a schema, rows, and a history of what changed them. It is the one place in BankSync where your financial data comes to rest instead of passing through on its way somewhere else.

By default BankSync is pass-through: a feed reads from your bank and writes to Google Sheets, Notion, a database, or your own endpoint, and nothing is retained. Storing data in a table is an explicit choice you make per feed. Once you make it, the same rows are available in four places at once.

The mental model#

Think of Tables as a small relational database with a spreadsheet-shaped interface:

1. Rows hold records. A transaction, vendor, invoice, or client is one row.
2. Fields give every value meaning. A Number behaves like a number everywhere; a Date behaves like a date everywhere.
3. Relations connect records. A vendor row can point to every transaction for that vendor.
4. Lookups, rollups, counts, and formulas answer questions. Show the linked dates, sum the linked amounts, count the linked rows, or write a custom expression.
5. Every surface reads the same result. The grid, dashboards, CSV export, REST API, MCP, and AI copilot all see the stored computed value.

That gives you a useful progression: store the rows first, connect them second, calculate third, and chart the answer last.

Learn Tables in seven short lessons#

If you only want bank data stored in BankSync, lessons 1–3 are enough. Continue through lessons 4–7 when you want Tables to become a connected model for vendors, clients, budgets, invoices, or other reference data.

Where tables live#

Tables get their own tab in the workspace tab bar, next to Integrations. The tab has two surfaces:

• The list. Every table in the workspace, with its kind, row count, which feeds write to it, and when it last changed. A folder tree on the left organizes them, the same way it organizes dashboards: drag to reorder or nest, rename inline, pick an emoji, mark favorites, search.
• The grid. Opening a table gives it the full page, because a spreadsheet needs the room. From the grid you can also open a side panel for the schema (the field editor), the connected feeds (what writes here, with links to each feed), and the activity log (what changed, when, and who did it).

Both are deep-linkable, so you can bookmark a table or paste a link to one into a message.

Typed and custom schemas#

Every table has one of two kinds of schema, and the badge next to the table name always tells you which.

A typed table is bound to one of the data contracts BankSync already uses for feeds: transactions, balances, holdings, trades, orders, loans, receipts, or invoices. Picking the type is all the configuration there is. You get one column per contract field, already typed and formatted, and the table is immediately usable as a destination for feeds of that type. Field mapping is automatic, because both sides speak the same contract.

A custom table has no contract behind it. You define the fields. Use one for the reference data that lives around your bank data: a chart of accounts, a category list, a client roster, a vendor-to-GL-code mapping you can then point an enrichment at.

Typed tables stay typed while you personalize them. Renaming a field, changing its format, reordering columns, or adding your own extra fields all keep the binding intact, and the badge just notes the extras, for example "Transactions · 2 custom fields". Removing or retyping one of the standard fields is different: it breaks the contract, so it requires an explicit conversion. See Creating and editing a table for how that works and why.

Fields, formats and computation#

A field has one kind, which decides what it holds, and a format, which only decides how it is displayed. Kinds fall into four groups:

• Basic — text, long text, number, checkbox, date, date & time, select, multi-select, status, URL, email, phone, rating, user, auto number, attachment and JSON. Enforced everywhere: in the grid, on API writes, on CSV import and on feed writes alike.
• Connected — a relation links rows to rows in another table, or in this one, and lookup, rollup and count read across that link.
• Computed — a formula calculates from this row and from the rows its relations point at.
• System — created time, last edited time, created by and last edited by, taken from the row's own history.

Formats are presentation only. Making a number render as US dollars, or a date render as 31/01/2026 instead of 2026-01-31, changes nothing about the stored value and can be undone at any time.

Computed values are stored on the row, not worked out as you look at them, so you can sort by a rollup, filter on a formula, chart and group one on a dashboard, and read one over the API exactly as you would a column you typed. A value that owes a recalculation says Recalculating rather than showing a blank it has not earned.

Full detail: field types, relations, lookups, rollups and counts, formulas.

Rows, deletes, and trash#

Rows arrive from feeds, from CSV import, from the API, or from you typing them into the grid. Every row records where it came from, so you can tell a synced row from one you added.

Deleting a row moves it to the table's trash rather than erasing it, and a synced row that you deleted will not reappear on the next sync. Deleting a table moves the whole table to trash, rows included, and warns you first if any feed writes to it. Anything in trash can be restored for 30 days, after which it is permanently purged.

Deleting your workspace, or withdrawing bank consent, purges the affected rows and any attached files immediately rather than waiting for the 30-day clock.

Working in the grid#

Beyond typing into cells, the grid gives you three ways to work with a table without leaving it:

• Expand a row into a drawer to see every property with room to work — long text, attachments, related rows, computed values, and the row's own activity log. Clicking a related row's chip opens that row, in its own table, with breadcrumbs back to where you started.
• Turn on a calculation under any column — count, sum, average, median, min, max, earliest, latest, percent filled, and more. The figure covers the whole table, not just the rows currently loaded on screen, and which calculations a column offers depends on what it can honestly answer: sum over a status column is not an empty result, it is a question with no meaning.
• Group rows by a select, status, checkbox, date, or relation field, and collapse the groups you are not working on.

Calculations and grouping are saved with the view you are in, so they are there next time you open it.

Views: more than one way to see a table#

Everything you arrange on a table — its filter, its sort, its grouping, which columns show and how wide, the footer calculations, the row colours — is a view, saved and switched from the tabs above the rows.

A view is one of seven layouts:

A view is shared with your workspace or personal to you. Changing a shared view stays local to you until you press Save, and Reset puts it back; a personal view just saves itself. Personal views are invisible to everyone else, and a table always keeps at least one shared view, so there is always a view your teammates can open.

You can also colour rows by a condition — overdue in red, paid in green — with the first matching rule winning.

Comments and history on a row#

Expand a row and you get two more tabs beside its properties:

• Comments — leave a note on the row, edit or delete your own, and resolve or reopen any of them. A question about a transaction lives on the transaction.
• History — who wrote this row, what changed, and what a sync did to it, comments included. A row keeps its history even after you move it to trash.

Plan limits#

Tables are limited on three axes: how many tables a workspace can have, how many rows it can store across all of them, and how much attachment storage those rows can use.

Your current usage against these limits is shown on the Tables list and in the Billing panel. At 80% of the row limit BankSync warns you; at 100% writes stop and say so loudly. See Using a table as a feed destination for exactly what a feed does when it hits the ceiling.

Where to go next#

• Creating and editing a table — pick a schema, edit fields inline, and change types safely.
• Field types in a table — every kind, the formats, and the caps.
• Relations between tables — link rows to rows.
• Lookups, rollups and counts — summarise across a relation.
• Formulas — the function list and the error states.
• Attaching files to a row — several files per cell.
• Importing a CSV — start a table from a file.
• Using a table as a feed destination — send a feed's data into a table in one click.
• Building widgets on a table — chart and aggregate stored data on a dashboard.
• Tables over the API — properties, keys and hasMore.