Digits

List the chart of accounts: every category with its name, type and id. This is the authoritative way to resolve an account name to its id — for a journal entry line, a filter, or anything else that needs a category_id. Called without a category_types filter this returns the whole chart of accounts, which is finite, so the account is either in the response or the legal entity does not have it; a retired account comes back with active false rather than being left out. Prefer this over search_term for an account: search_term matches fuzzily against ledger activity, which is a different question and can fail when a view is unavailable.

List accounts-receivable invoices synced in from another accounting provider (e.g. QuickBooks) through Connect, for a business. This is separate from list_invoices, which only covers invoices native to Digits invoicing and never includes these. A request for every invoice this business has, across every source, requires also calling list_invoices; call both and combine the results. Status here is derived rather than stored, since Connect doesn't carry Digits' invoice status: "Paid" once the invoice is fully settled, "Voided" once reversed, or "Created" while still open — there is no draft/sent distinction. Optionally pass paid_since_days to drop paid invoices older than that, while still showing every open one. Each result is a summary — status, dates, amounts, and customer, but not line items or discounts.

List the entity's departments: every department with its name, active status and id. This is the authoritative way to resolve a department name to its id — for a transaction line, a filter, or anything else that needs a department_id. Called without a status filter this returns the whole finite list, so the department is either in the response or the legal entity does not have it; a retired one comes back with active false rather than being left out. Prefer this over search_term for a department: search_term matches fuzzily against ledger activity, which is a different question, and a miss there says nothing about whether the department exists.

List the invoice customers (bill-to recipients) configured for a business, optionally filtered by a search string matched against the customer's name and email. Use this to find the customer_id to pass to create_invoice, or to check whether a customer already exists before billing one by name.

List DigitsLedgerInvoicing accounts-receivable invoice summaries for a business. This covers only invoices native to Digits invoicing — it never includes invoices synced in from another accounting provider through Connect (e.g. QuickBooks), even with status "all". A request for every invoice this business has, across every source, requires also calling list_connect_invoices; call both and combine the results. Pass status to choose which invoices to see: "pending" for draft, sent, or awaiting-payment invoices; "paid" for paid, processing, or settled invoices; "voided" for voided invoices; "all" for every status, including exceptional ones like cancelled, refunded, or payment-failed that the other three don't cover. Optionally filter to one customer with customer_id from list_invoice_customers. Each result is a summary — status, dates, amounts, and customer, but not line items or discounts.

List the entity's locations: every location with its name, active status and id. This is the authoritative way to resolve a location name to its id — for a transaction line, a filter, or anything else that needs a location_id. Called without a status filter this returns the whole finite list, so the location is either in the response or the legal entity does not have it; a retired one comes back with active false rather than being left out. Prefer this over search_term for a location: search_term matches fuzzily against ledger activity, which is a different question, and a miss there says nothing about whether the location exists.

Query and filter individual transactions. This tool provides access to transaction-level data with flexible filtering capabilities. For aggregated summaries, use the "dimensional_summarize_transactions" tool instead. For bill or invoice questions, answer only from explicit fields returned by tools; do not infer missing bill or invoice details from transaction summaries. ## Required Parameters **origin**: Time period specification. All fields must be set. - interval: "Day", "Week", "Month", "Quarter", or "Year" - year: Calendar year (e.g., 2024) - index: Position within year (1-12 for Month, 1-4 for Quarter, etc.) - interval_count: Number of periods to include Example: {"interval": "Month", "year": 2024, "index": 11, "interval_count": 1} means November 2024 ## Optional Parameters **filter**: Transaction filtering criteria: - minimum/maximum: USD dollar amounts as numbers (e.g., 10000 or 1250.75) - occurred_after/occurred_before: Timestamps for date filtering - category_ids: {"ids": ["cat-id-1", "cat-id-2"]} - category_types: {"types": ["Expenses", "Income", etc.]} - party_ids: {"ids": ["party-id-1"]} — requires either category_types or party_roles - party_roles: ["EntityVendorRole", "EntityCustomerRole", etc.] - digits_transaction_types: Filter by transaction type (PayIn, PayOut, JournalEntry, BankTransfer) **order**: Sort order for results **direction**: Direction from origin (Past or Future) **pagination**: Page controls. Defaults to {"offset": 0, "limit": 250} when omitted. ## Example Request { "origin": {"interval": "Month", "year": 2024, "index": 11, "interval_count": 1}, "filter": { "minimum": 10000, "category_ids": {"ids": ["cat-id-123"]} } } ## Response Format Returns: - transactions: Array of transaction objects - partial_data: Whether data is filtered by permissions - transaction_context: Additional context keyed by transaction ID ## Best Practices 1. **Use appropriate time ranges**: Set interval_count to cover your desired period 2. **Filter for relevance**: Use filter parameters to narrow down results

Read one DigitsLedgerInvoicing invoice in full by its id. What it returns is an update_invoice payload. Send it back as-is, changing only what the user asked for: update_invoice REPLACES the invoice with what you send, so a line, discount, memo or reference number you drop from this payload is deleted from the invoice. Copy line_item_id onto the line that replaces it and discount_line_id onto the discount that replaces it. They say which row each one is, so the order you send them in stops mattering and a removed row is unambiguous. Leave them unset only on a line or discount you are adding. Do not send catalog links back, and do not invent them: the catalog product a line bills and the catalog discount a discount comes from are preserved for every row you return with its id, which is why no product_id or discount_id appears here. status, currency_code, category_name, amount and a discount's currency are yours to read, not to send back; update_invoice ignores them, and takes a line's currency from the line itself. Use the invoice_id returned by create_invoice, or the one in a digits-entity://invoice/... link from earlier in this conversation.

Resolve a customer, vendor, party name or transaction description to its canonical form using fuzzy text matching. That open-ended set is what this tool is for. It can also match category, department and location names, but the list tools are definitive for those: list_categories, list_departments and list_locations each return a whole finite list, so the name is either in it or this legal entity does not have one, whereas a miss here only means nothing in the ledger activity matched. Before using an ID this tool returned in transaction filters, run a final search on the full phrase and verify the selected canonical name matches the intended phrase (for example, do not treat "Uber" as a definitive match for "Uber Eats"). An id from list_categories, list_departments or list_locations is already exact and needs no confirming search. If multiple close matches remain after full-phrase search, ask the user to confirm which one they mean before proceeding. ## Required Parameters **text**: The search query string. This is the user-entered term to match against canonical names (e.g., "uber eats", "office supplies"). ## Optional Parameters **kinds**: List of object kinds to search across. Valid values: "Party", "Category", "Department", "Location", "Transaction". - When searching for terms related to a transaction, always pass the full kinds list exactly as: ["Party", "Category", "Department", "Location", "Transaction"]. Do not pass a partial subset for transaction-term searches. - If omitted, defaults to a limited set of kinds automatically. **sort**: List of sort orderings for results. Each entry has: - field: "Score", "Date", "DisplayNumber", "Name", or "Type" - ascending: boolean (default false = descending) Example: { "text": "uber eats", "kinds": ["Party", "Category", "Department", "Location", "Transaction"] }

Select a business to work with. After calling this tool, use the returned business ID as business_id in subsequent tool calls.

Turn a category in a business's chart of accounts on or off. A category can never be deleted. Turning it off is how a category is retired: it stops being offered for classifying transactions, and existing transactions keep their history. Turning it back on restores it. Turning a category off also turns off every category nested under it. A category that is mapped to a connected accounting integration or to bill pay or invoicing cannot be turned off — retire the mapping first. enabled must be stated explicitly: true to turn the category on, false to turn it off. Resolve category_id with list_categories.

Edit an existing category in a business's chart of accounts. Supply category_id plus only the fields to change; anything omitted keeps its current value. To clear the description or the account number, pass an empty string for it explicitly. Resolve category_id and parent_category_id with list_categories. Two behaviors to warn the user about before calling: editing a category that is currently turned off turns it back on, along with every category above it; and changing type or subtype applies the same change to all of its subcategories. A top-level root category's name, type, subtype and parent cannot be changed, and the type or subtype of a category connected to bill pay or invoicing cannot be changed.

Update an existing DRAFT accounts-receivable invoice for a business, replacing its contents. This is a full replacement, not a partial edit: the invoice is re-saved from exactly what you pass, so supply the COMPLETE invoice — every line item and discount you want it to keep. Anything you omit is removed. Call read_invoice first and send its payload back with only the field the user asked about changed; it returns exactly what this tool takes. Only draft invoices can be edited this way. Editing a sent invoice's customer, amounts, dates, or presentation is rejected; a sent invoice's line items can only be recategorized, which update_transaction_fields does directly. Provide invoice_id (from create_invoice) to target the invoice — it must belong to an existing invoice, or the update is rejected — and invoice_number to keep the invoice's existing number, since a re-save takes the number verbatim. Customer and catalog products resolve exactly as in create_invoice, but because this is a full replacement, customer_id or customer_name must be supplied on every update too — omitting both removes the invoice's customer rather than keeping the existing one. Set line_item_id on every line that already existed and discount_line_id on every discount that already existed, copying both from read_invoice. They identify which row each one replaces, so the order you send rows in stops mattering and a removed row is unambiguous. Leave them unset only on a row you are adding. An id that is not on the invoice — for a discount attached to a line item, one that is not on that line — or an id used twice is rejected before any write. A row you leave unclassified (no income_category_id/department_id/location_id) inherits the classification of the row it replaces, and so do the catalog links: a line keeps the catalog product it was billing and a discount keeps the catalog discount it came from. That inheritance is the one exception to restating everything, and the catalog links are what it matters most for. Do not copy product_id or discount_id back from read_invoice — each is only accepted together with the catalog source id it belongs to, which read_invoice does not report, so a restated one is rejected. The invoice's branding is preserved for you: this tool reads the draft's branding and carries it onto the replacement, so an edit never strips it. profile_id is not — no read exposes a draft's invoicing profile, so a business with more than one profile must be given profile_id or the update is rejected with the profiles to choose from.

Edit a manually-created journal-entry transaction: replace its date, memo, and lines. Unlike update_transaction_fields (which only relabels an existing transaction), this rewrites the substance of the entry — amounts, dates, and which categories are debited and credited. It only works on transactions that were entered manually (for example via create_transactions); transactions synced from a connection (such as a bank or QuickBooks) cannot be edited this way. To relabel a synced transaction, use update_transaction_fields instead. Identify the entry with any of its transaction_fact_ids (use query_transactions to resolve). Provide the complete new set of lines — the given lines fully replace the existing ones, so include every line the entry should end up with, and they must balance (total debits equal total credits). To edit an existing line in place, set its transaction_fact_id (from query_transactions) on the line you're replacing it with; omit it to add a brand-new line. Any existing line whose transaction_fact_id you don't include is removed. Resolve category_id via list_categories, party_id via search_term, department_id via list_departments, and location_id via list_locations. To attach a party that does not exist yet, set party_name instead of party_id and it will be created. Use memo for the overall journal entry and lines[].description for each line's memo. Omit a named existing line's description to preserve it, or set description to an empty string to clear it. A new line has no description unless one is supplied. If the transaction falls in a closed accounting period the edit is rejected, and if the current view is stale it should be retried.

Recategorize one or more existing transactions for a business by their transaction fact IDs. This changes only the labels on a transaction — its category, party (vendor/customer), department, location, or tax status. It never changes the amount, date, or direction. It works on any transaction, including ones synced from a connection (such as a bank or QuickBooks). Resolve transaction_fact_ids via query_transactions, and resolve category_id via list_categories, party_id via search_term, department_id via list_departments, and location_id via list_locations before calling this tool. Provide at most 100 updates per call and at least one field to change per update; fields left unset are unchanged, and a field can be changed but not removed. Scheduled transactions cannot be edited this way. If the current view is stale, the update is rejected and should be retried.

Void a sent accounts-receivable invoice for a business by its invoice ID. Voiding reverses an invoice that has already been sent and posted to the books: the receivable is written off and the invoice is marked void, leaving an audit trail rather than erasing it. A draft invoice is not posted, so delete it with delete_invoice instead of voiding it. The invoice ID is the invoice_id returned by create_invoice.