@get-asset/react
AssetTransactions
Styled transactions table showing each transaction's date, description, account, amount 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
Transactions
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:create
API reference
Root props
| Prop | Type | Default | Description |
|---|---|---|---|
year | number | — | Override the AssetProvider's year for the date range. |
month | number | null | — | Override the AssetProvider's month (1-12); null forces the whole year. Omit to inherit the provider's month. |
plan | "managed" | "diy" | — | Override the business plan — "managed" (Done for you) or "diy" (Do it yourself). Drives the status labels and filter options (see Plan behaviour). Defaults to the fetched plan, or "managed". |
startDatetime | string | — | ISO datetime overriding the start of the provider-derived year/month period. |
endDatetime | string | — | ISO datetime overriding the end of the provider-derived year/month period. |
accountIds | string[] | — | Only include transactions for these external account ids. |
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
Transactions
Transactions
Transactions
Transactions
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
Asset businesses are on one of two plans, and some components behave differently on each. On Done for you (the managedplan) a bookkeeper reviews and categorises the business's books for them; on Do it yourself (the diy plan) there is no bookkeeper, so the business keeps its own books. 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 |
|---|---|---|
| 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). |