@get-asset/react
Transactions
Styled transactions table showing each transaction's date, description, account, amount — printed with its own currency's symbol and followed by the ISO code, muted — and category. The header carries status and account filter dropdowns, and a “load more” banner at the bottom fetches the next page. Payment-only transactions are excluded by default. Pending rows carry confirm and provide-context actions; the latter reveals an inline form for adding context before submitting.
Built on the headless Transactions compound from @get-asset/sdk.
Preview
Loading preview…
Required scopes
The access token used by AssetProvider must include these scopes for this primitive to fetch data successfully:
transaction:readtransaction:updateexternal_account:readbusiness:readtag:readjournal_entry:readjournal_entry:createchat:create
API reference
Root props
| Prop | Type | Default | Description |
|---|---|---|---|
dateFrom | CalendarDateString | — | Inclusive start (YYYY-MM-DD) of a fixed reporting range. Setting it detaches the table from the provider's shared range entirely; must be paired with dateTo (one without the other throws). Use periodDateRange to derive the pair from a month, quarter, or year. |
dateTo | CalendarDateString | — | Inclusive end (YYYY-MM-DD) of a fixed reporting range. Must be paired with dateFrom. Omit both to follow the provider's DatePicker-driven range. |
plan | "managed" | "diy" | "core" | — | Override the business plan — "managed" (Done for you), or "diy" / "core" (Do it yourself, identical behaviour). Drives the status labels and filter options (see Plan behaviour). Defaults to the fetched plan, or "managed". |
accountIds | string[] | — | Only include transactions for these external account ids. |
hiddenColumns | TransactionsColumn[] | — | Columns to omit from the table. Options: "date", "transaction", "tag", "account", "amount", "status", and "category". All columns are shown by default. |
ledgerType | LedgerType | — | Only include transactions whose journal entry has a line in a ledger of this type (e.g. "expense"). Always applied to the fetch. Ignored when ledgerSubtype is also set — the subtype is more granular and already implies its type. |
ledgerSubtype | LedgerSubType | — | Only include transactions whose journal entry has a line in a ledger of this subtype (e.g. "operating_expense"). Always applied to the fetch. Takes precedence over ledgerType — when both are set only the subtype is sent to the API. |
pageSize | number | — | Page size passed to the API. |
entries | TransactionOverride[] | — | Override the rows shown. Skips the API call. |
tagFields | TransactionTagField[] | — | Override the fetched tag fields (name + values), skipping the fetch. Pass [] to hide the Tag column entirely (see Tags). |
allowCreateTag | boolean | true | Allow creating new tag values from the picker (see Tags). |
onTagsChanged | (transaction, field, values) => void | — | Notification fired once per edited field after a successful tag write. |
state | "loading" | "error" | "empty" | — | Force a specific state for testing. |
className | string | — | Forwarded to the outer container element. |
States
Loading preview…
Loading preview…
Loading preview…
Loading preview…
Loading preview…
Tags
Whenever the business defines at least one tag field, a Tag column appears between Transaction and Account (and is hidden entirely otherwise). The closed state shows a quiet [+] when a row is untagged, its first value once tagged, and value +N when it carries more — hover to see the full set. On mobile the same control sits inline next to the category chip instead of its own column.
Clicking the trigger opens a searchable picker grouped by field; typing a value that doesn't exist yet on a field reveals an Add "…" to <Field> row that creates it (disable this with allowCreateTag={false}).
Edits write per field, and when a field ends up with more than one value the transaction's amount is split evenly across them in reports — see the SDK page's Tags section for the full write semantics.
Plan behaviour
Some components behave differently depending on whether a bookkeeper keeps the business's books. On Done for you (the managed plan) a bookkeeper reviews and categorises the books for them. On Do it yourself (the diy and core plans) there is no bookkeeper, so the business keeps its own books — core behaves exactly like diy everywhere below. The plan is resolved from the business automatically — override it with the plan prop.
The table shows the same columns on either plan, but the status labels a customer sees, the status filter options, and the result of submitting context all depend on whether a bookkeeper is in the loop:
| Behaviour | Done for youmanaged | Do it yourselfdiy core |
|---|---|---|
| Status labels | Needs Attention, In Review (with the bookkeeper) and Confirmed. | Needs Attention and Confirmed only — with no bookkeeper, an in-review transaction still reads Needs Attention. |
| Status filter | Needs Attention / In Review / Confirmed. | Needs Attention / Confirmed. |
| Submitting context | Hands the transaction back to the bookkeeper. | Advances the transaction into review itself (no bookkeeper to do it). |