---
title: "Creating and Editing a Table"
description: "Create a table from a standard schema or define your own fields, then rename, reorder, pin, retype, and reformat columns inline in the grid."
section: "Tables"
canonical: "https://banksync.io/docs/tables/tables-create"
---

You can create a table two ways: from a standard BankSync schema, or from scratch. Both land you in the same grid, where every part of the schema is editable in place. This guide covers creating a table, editing its fields, and the one change that needs an explicit decision from you.

> **Before you start:** 'Tables are in beta and are enabled per workspace. You need the editor role or higher to create a table or change its schema; viewers can read a table but not edit it. Read the Tables overview first if you have not already.'

## The short version

- Choose a **typed table** for bank, brokerage, or document data. BankSync creates and protects the standard fields for you.
- Choose a **custom table** for your own reference data, such as vendors, clients, budgets, or a chart of accounts.
- A field's **kind** controls what can be stored; its **format** only changes how the value looks.
- Adding, renaming, reordering, pinning, or reformatting fields is safe. Removing or retyping a standard field requires an explicit conversion to Custom.

## Create a table from a standard schema

This is the path to use whenever the table will hold bank data. Picking the data type is the whole configuration step.

**Create a typed table**

1. **Open the Tables tab** — Go to the Tables tab in your workspace and click "New table".
2. **Pick a standard schema** — Choose the data type the table will hold: Transactions, Balances, Holdings, Trades, Orders,
   Loans, Receipts, or Invoices.
3. **Name it** — Give the table a name and, if you want, an emoji. Both can be changed later by clicking them in
   the grid header.
4. **Create** — BankSync generates one column per field in that data type, already typed and formatted. Amounts
   arrive as currency, dates as dates, statuses as select fields.

The table is now a valid destination for any feed carrying that data type, with field mapping already done. Nothing else to configure.

## Create a custom table

Choose "Custom" instead of a data type when the table holds your own reference data rather than bank data: a chart of accounts, a category list, a client roster, a vendor mapping.

**Create a custom table**

1. **Choose Custom** — In the New table dialog, pick "Custom" instead of a data type.
2. **Define your first fields** — Add each field with a name and a type. You can add the rest later from the grid.
3. **Create, then fill it** — Type rows straight into the grid, paste them in, or import a CSV.

You can also start from a CSV: BankSync reads the header row and a sample of the data, proposes a field for each column with a type it inferred, and lets you correct anything before the import runs. See [Importing a CSV](/docs/tables/tables-csv-import).

## Editing fields in the grid

Everything about a field is editable from the grid itself. None of these actions touch your data.

| To do this            | Do this                                                                              |
| --------------------- | ------------------------------------------------------------------------------------ |
| Rename a field        | Double-click the column header and type. Enter commits, Escape cancels.              |
| Reorder columns       | Drag a column header left or right.                                                  |
| Pin a column          | Open the column menu and choose "Pin left" or "Pin right".                           |
| Hide or resize        | Column menu, or drag the edge of the header.                                         |
| Change type or format | Open the Fields rail ("Fields" in the table's header band) and edit the field there. |
| Add a field           | Click the "+" at the right end of the header row.                                    |
| Add a row             | Click the "+ New row" row at the bottom of the grid.                                 |

Renaming is safe on any field, including the standard ones. BankSync tracks a field by a hidden, stable id rather than by its name, so a rename never rewrites data, never breaks a feed's mapping, and never breaks a dashboard widget pointed at that field. Call the `description` column "Merchant" if that is what your team calls it.

Column order, widths, pinning, visibility, sort, and density are shared across the workspace: arrange a table once and everyone sees it that way. They are display settings and are stored separately from the schema.

## Types, formats, and enforcement

Open the Fields rail from the table's header band and each field gives you two separate things.

**The kind** decides what the field accepts. There are seventeen basic kinds — text, long text, number, checkbox, date, date & time, select, multi-select, status, URL, email, phone, rating, user, auto number, attachment and JSON — plus relations, lookups, rollups, counts, formulas and the four system kinds. [Field types in a table](/docs/tables/tables-fields) lists them all, and says which ones are read-only.

**The format** decides only how the value is displayed:

- **Number fields** can render as a plain number, a currency, or a percentage. Pick the currency by its ISO code (`USD`, `AUD`, `GBP`) and set how many decimal places to show.
- **Date fields** can render as ISO (`2026-01-31`), medium (`31 Jan 2026`), long (`31 January 2026`), US numeric (`01/31/2026`), EU numeric (`31/01/2026`), or relative (`3 days ago`).
- **Datetime fields** offer the same presets with a time component.
- **Text fields** can render as plain text, a link, or an email address.

Changing a format is instant, lossless, and reversible, because the stored value never changes. Turning a number column into a currency column is a display decision, not a migration.

Kinds, by contrast, are enforced everywhere the data can be written:

1. **In the editor.** A number field gives you a numeric input and a date field gives you a date picker, so most invalid values cannot be typed at all.
2. **On commit.** Anything that slips through is rejected before it is saved. The cell shows a red outline with the reason and stays open so you can fix it.
3. **On every other write path.** Feed writes, CSV imports, and API writes are validated against the same rules. There is no back door that lets bad data in behind the grid's back.

> **Changing a field's type can lose values:** 'Before a retype is applied, BankSync reads every value stored in that field and tells you how many the new type cannot read, for example "312 of 5,204 values cannot be read as numbers". You then choose: save the change anyway, or cancel. A retype is never applied silently. Values the new type cannot read keep whatever is stored today and are rejected the next time that cell is edited, so review them before you commit. Where a field holds more distinct values than BankSync will check in one pass, it says it could not count them rather than showing you a figure it estimated.'

## Removing or retyping a standard field

On a typed table, the fields that came from the standard schema cannot be deleted or retyped while the table stays typed. To do it, you first convert the table to a custom schema, from the table's menu → "Convert to custom schema".

This is deliberate, and worth understanding before it surprises you.

A typed table's value is that its shape matches a contract BankSync knows. That is what lets a feed write to it with no mapping step, what lets the badge promise a widget that the `amount` column really is the transaction amount, and what lets the API describe the table to an agent. Delete the `amount` column, or turn `date` into free text, and none of those promises hold any more. The table is still perfectly useful, but it is now your shape rather than a standard one.

So BankSync makes you say so. Converting flips the badge to "Custom", drops the standard-field markings, and hands you full control of every field. Nothing about your rows changes. What you give up is the automatic behavior: the table is no longer offered as a zero-setup destination for that data type.

> **Adding your own fields does not convert anything:** 'Adding custom fields, renaming labels, reordering, pinning, and changing formats all keep a typed table typed. The badge just notes the extras, for example "Transactions · 2 custom fields". Only removing or retyping a standard field requires the conversion.'

Conversion is blocked while a feed still writes to the table, because typed feed writes depend on the binding. Disconnect or repoint the feed first, then convert.

## Editing rows

You can edit any cell in any table, including cells that a feed fills. Two things are worth knowing:

- **A feed can overwrite what you typed.** Columns filled by a feed carry a marker in their header, and the first time you edit one BankSync tells you this once. If your bank later revises that row, for example when a pending transaction posts, the bank's value wins.
- **Notes belong in your own columns.** Add a custom field for anything you want to keep permanently. Feeds never write to columns they do not own, so your notes are safe there.

Category-style edits are the exception: BankSync learns them and re-applies them on every later sync, so recategorizing a merchant sticks.

Deleting a row moves it to the table's trash, and a deleted synced row is not resurrected by the next sync. Restore it from the trash view within 30 days.

## Where to go next

- [Field types in a table](/docs/tables/tables-fields) — the full field vocabulary, formats and caps.
- [Relations between tables](/docs/tables/tables-relations) — link this table's rows to another's.
- [Using a table as a feed destination](/docs/tables/tables-destination) — fill the table you just made.
- [Building widgets on a table](/docs/tables/tables-widgets) — chart it on a dashboard.