whoami |
Your identity, organization and scopes. |
|
GET /v1/me |
list_entities |
Legal entities (companies) with functional currency and country. |
|
GET /v1/entities |
search_accounts |
Find accounts by code prefix or name; returns code, name, type and role. |
entity_code, query (optional) |
GET /v1/entities/{entity}/accounts |
find_records |
Find invoices, bills, credit notes, purchase orders, journal entries, payments, customers, vendors, subscriptions, revenue contracts, deals, products and plans of every entity by number, reference, code, name, title, customer or VAT number (numbers compared on letters and digits only); best match first, at most limit (1 to 20) of each type. |
query, limit (optional) |
GET /v1/search |
list_roles |
The ready-made and the organization's own roles: each one's rights, the areas of the app it opens, which sales records its people see, what it allows and does not allow in plain words, and how many people have it. Needs the admin scope. |
|
GET /v1/roles |
see_access_as |
What a person (user_id, from list_people) can open and do, in plain words: the areas they open and do not, what they can and cannot do, which sales records they see, whether they approve and when their access ends. Needs the admin scope. |
user_id |
GET /v1/roles/people/{user_id}/preview |
unused_rights |
Rights and areas people have not used for 90 days, and people who used nothing: each with why. The administrator takes them away with one click at the link. Needs the admin scope. |
|
GET /v1/roles/suggestions |
get_company_brand |
A company's logo (its address and size), brand and accent colours, the theme of the app (light, dark, system) and the contrast of the colours in use against white. |
entity_code |
GET /v1/entities/{entity}/brand |
update_company_brand |
Change a company's look: changes: {theme? (light, dark, system), colour? (#rrggbb, the buttons, links and document titles; at least 4.5:1 against white), accent? (#rrggbb, the rules and e-mail band; at least 3:1)}. null sets a colour back to the default. Needs the admin scope. |
entity_code, changes |
PATCH /v1/entities/{entity}/brand |
set_company_logo |
Make an image the company's logo: image_base64 is a PNG, JPEG, WebP or GIF file in base64, at most 2 MB (SVG is refused). It is kept as a PNG of at most 1200 x 480 pixels and shows on the app's top bar, the PDFs, the e-mails, the quote page and the website forms. Needs the admin scope. |
entity_code, image_base64, filename (optional) |
POST /v1/entities/{entity}/brand/logo |
remove_company_logo |
Remove a company's logo: its documents and pages show its name alone. Needs the admin scope. |
entity_code |
DELETE /v1/entities/{entity}/brand/logo |
cash_flow |
Cash flow statement (indirect method) for a date range: operating, investing and financing activities, each line with its accounts; balanced confirms opening cash plus the net change is the closing cash. |
entity_code, start, end |
GET /v1/entities/{entity}/reports/cash-flow |
trial_balance |
Account balances (functional currency) as of a date (ISO). |
entity_code, as_of |
GET /v1/entities/{entity}/reports/trial-balance |
profit_and_loss |
Income statement for a date range, grouped by report line. currency (e.g. EUR) shows it in another currency: each month at its average ECB rate. |
entity_code, start, end, currency (optional) |
GET /v1/entities/{entity}/reports/profit-and-loss |
balance_sheet |
Balance sheet at a date; balanced confirms assets = liabilities + equity. currency (e.g. EUR) shows it in another currency (IAS 21), with the translation difference in translation. |
entity_code, as_of, currency (optional) |
GET /v1/entities/{entity}/reports/balance-sheet |
general_ledger |
Postings on one account with running balance; cites journal entry numbers. |
entity_code, account_code, start, end |
GET /v1/entities/{entity}/reports/general-ledger |
saved_report_sources |
What a report can list: invoices, bills, customers, vendors, deals, leads, payments, purchase orders, subscriptions, journal lines and products, each with its fields (type, the values of a list, whether a report may group by it). Read it before run_report. |
language (optional) |
GET /v1/saved-report-sources |
run_report |
Build a list or report the person asks for in words, and run it. definition: {source, columns? (fields shown), filters? [{field, op (eq, ne, gt, gte, lt, lte, in, not_in, contains, between, empty, set), value}], group_by? (one field: a line per value with count and sums), sums? (amounts to add up), sort? [{by, descending}], limit? (1 to 500)}. Dates may be relative: today, today-30, start_of_month, end_of_last_quarter, ...; a person may be "me". Example, unpaid invoices over 10,000 in Germany by sales person: {"source": "sales_invoices", "filters": [{"field": "kind", "value": "sales_invoice"}, {"field": "payment", "op": "in", "value": ["open", "overdue"]}, {"field": "open_amount", "op": "gt", "value": "10000"}, {"field": "country", "value": "DE"}], "group_by": "sales_person"}. Each row has its link in the app; each group the definition of its rows (drill). save_report keeps it. |
entity_code, definition, language (optional) |
POST /v1/entities/{entity}/saved-reports/run |
list_saved_reports |
The person's saved reports of a company and those shared with them, pinned first, each with its definition, sharing, e-mail schedule and link. |
entity_code |
GET /v1/entities/{entity}/saved-reports |
run_saved_report |
Run a saved report as of today, as the person sees it. |
report_id, language (optional) |
GET /v1/saved-reports/{report_id}/result |
save_report |
Keep a report for the person: definition as for run_report; name (default: the source's); sharing {everyone?, people? [user ids]}; schedule {every (day, week, month), weekday? (0 Monday), day? (1-28), hour? (company time, default 7), recipients? [user ids: the owner and people it is shared with]} e-mails it; pinned puts it on their Home. Ask the person before sharing or scheduling. |
entity_code, definition, idempotency_key, name (optional), sharing (optional), schedule (optional), pinned (optional) |
POST /v1/entities/{entity}/saved-reports |
update_saved_report |
Change a report of the person's own: changes: {name?, definition?, sharing?, schedule?, unschedule? (true stops the e-mails)}. |
report_id, changes |
PATCH /v1/saved-reports/{report_id} |
delete_saved_report |
Delete a report of the person's own; ask them first. |
report_id |
DELETE /v1/saved-reports/{report_id} |
get_journal_entry |
A journal entry with lines, provenance and hash. |
entry_id |
GET /v1/journal-entries/{entry_id} |
search_journal_entries |
Posted and pending entries by description text and date range (newest first). |
entity_code, text (optional), start (optional), end (optional), limit (optional) |
GET /v1/journal-entries |
create_journal_entry |
Create and submit a balanced journal entry. Each line: {account, debit|credit, currency?, fx_rate?, dimensions?, description?}. fx_rate is units of functional currency per unit (default the ECB rate of the entry date); a rate more than 10% from it is refused (fx_rate_implausible) unless confirm_rate, which you set only after the person confirmed that rate. dimensions assigns the line's cost centre, profit centre or project: {"cost_centre": "CC-100"} (values from list_dimensions); an account may require one (dimension_required), so ask the person which when it is not clear. The policy decides whether it posts or waits for a human; see result.status and result.policy.reason. |
entity_code, entry_date, description, lines, idempotency_key, confirm_rate (optional) |
POST /v1/journal-entries |
reverse_journal_entry |
Reverse a posted manual entry (a person's tool: agents are refused). The reason is required. status posted returns the reversal; status pending_approval means a second person must approve it (approval_id). Subledger entries are refused (409), naming where their correction belongs. |
entry_id, reason, idempotency_key, on (optional) |
POST /v1/journal-entries/{entry_id}/reverse |
list_pending_approvals |
Items waiting for a human decision, with the policy reason. |
|
GET /v1/approvals |
verify_ledger_integrity |
Recompute the tamper-evident hash chain of posted entries. |
entity_code |
GET /v1/entities/{entity}/chain-verification |
create_party |
Create a customer or vendor. party: {kind: customer|vendor, code? (left out: the company's next number, C-00001 or V-00001), name, country? (ISO; default: the one its VAT number names, else the company's), subdivision?, vat_number?, business (bool), currency? (default: its country's if the company has rates for it, else the company's), language? (default: its country's if it has one), payment_terms_days?, default_account?}. The answer is the party as created, with what was filled in. |
entity_code, party, idempotency_key |
POST /v1/entities/{entity}/parties |
create_document |
Create and submit a sales invoice, purchase bill or credit note. document: {entity, kind: sales_invoice|purchase_bill|sales_credit_note|purchase_credit_note, party (code), document_date? (sales: default today; a bill's is the date the vendor printed, required), due_date?, due_date_convention? (following|modified_following: roll a due date from payment terms onto a business day), currency? (default the party's), external_number?, credits?, order_reference? (of a bill: the purchase order number it names, matched against that order; see get_bill_match), lines: [{product? (code, sales only), description? and unit_price? (default the product's name and the customer's or list price; required without a product), quantity? (default 1), account? (default the product's, else the party's, else the company's), supply_type?, rate_type? (default the product's), tax_category?, printed_tax_amount?, discount_percent? | discount_amount?, dimensions? ({"cost_centre": "CC-100"}, values from list_dimensions)}], discount_percent? | discount_amount? (a discount on the whole document, split over the lines)}. Give only what you know; never guess a price. VAT is determined by the reference-data service on the discounted net; the response shows the tax treatment per line, whether posting awaits approval, and filled: what the system set and from where. |
document, idempotency_key |
POST /v1/documents |
record_payment |
Record a payment and allocate it. payment: {entity, direction: incoming|outgoing, party, payment_date? (default today), amount, currency?, bank_account?, reference?, allocations: [{document (number or id), amount, document_amount?}], party_kind?}. amount is in the payment currency; document_amount is what it settles on a document in another currency, in that currency (default: the payment day's rate). |
payment, idempotency_key |
POST /v1/payments |
reverse_payment |
Reverse a posted payment or receipt: an entry of its own undoes it (FX and cash discount included) and the documents it settled are open again. reason is required; on (ISO date, default today) must be in an open period. An agent's reversal always waits for a person: status posted with reversal.approval_id. A payment matched to a bank line is refused (409): the match is undone in the bank reconciliation. |
payment_id, reason, idempotency_key, on (optional) |
POST /v1/payments/{payment_id}/reverse |
customer_statement |
A customer's statement of account on a day (as_of, ISO date): the open items (credit notes negative), the balance and the open amount per age band for each currency, the totals in the functional currency and their tie to the receivables control account (reconciliation, unexplained is zero when the statement agrees with the ledger). Allocations dated after as_of are not counted. customer is the customer's code or id. It posts nothing; issuing the PDF is a person's act. |
entity_code, customer, as_of |
GET /v1/entities/{entity}/customers/{party}/statement |
customer_activity |
What a customer owes us and how it came about, from start to end (ISO dates): per currency the opening balance, each invoice, credit note and payment received with the running balance, and the closing balance, plus the items still open at the end and the closing balance in the functional currency. customer is the customer's code or id. Read-only. |
entity_code, customer, start, end |
GET /v1/entities/{entity}/customers/{party}/activity |
vendor_statement |
What we owe a vendor and how it came about, from start to end (ISO dates): per currency the opening balance, each bill, credit note and payment with the running balance, and the closing balance, plus the bills still open at the end. vendor is the vendor's code or id. Read-only. |
entity_code, vendor, start, end |
GET /v1/entities/{entity}/vendors/{party}/statement |
reminders_due |
Which customers are due a reminder letter today: per customer and currency the level (1 payment reminder, 2 second, 3 final), the invoices and the total, the letters made but not handed over yet, and those out of date that wait to be withdrawn. Read-only: a person makes, sends and withdraws the letters. |
entity_code |
GET /v1/entities/{entity}/reminders/proposal |
invoice_content_rules |
What an invoice of the company must show by the law of its country: the fields of the company profile (seller) and of a customer's record (buyer), each with its legal basis and whether every invoice needs it or only some. Read-only. |
entity_code |
GET /v1/entities/{entity}/invoice-content |
invoice_output_check |
Whether a sales invoice or credit note is ready to print and send (document: its id, or its number when no other company uses it): its status (only a posted one is output), missing_content (fields the law requires that the company's or the customer's record lacks, with the record to complete; printing and sending are refused until they are filled), sending (whether this server e-mails at all, the recipient it would use, the customer's addresses a send may go to, whether the XRechnung XML would be attached, and the sent log) and, for a German company, xrechnung (the EN 16931 and XRechnung check: valid and the rules it breaks, such as a missing Leitweg-ID). Read-only. Tell the person what is missing and ask them for it, or to complete the record; sending is the person's act, on the document's page (link). |
document |
GET /v1/documents/{document_id}
GET /v1/documents/{document_id}/dispatches
GET /v1/invoices/{invoice}/xrechnung |
receivable_allowance_proposal |
What the allowance for doubtful receivables should be at the period end, invoice by invoice (aging bucket or doubtful percent), and adjustment, what a run posts. Show it to the person before run_period_end with step receivable_allowance. Posts nothing. |
entity_code, fiscal_year, period |
GET /v1/periods/{period_id}/receivable-allowance |
aging_report |
Open receivables or payables (side) by due-date bucket as of a date. |
entity_code, side, as_of |
GET /v1/entities/{entity}/reports/aging |
flux_analysis |
Account movements vs the previous period; rows above materiality are flagged. |
entity_code, fiscal_year, period, materiality (optional) |
GET /v1/entities/{entity}/analytics/flux |
unusual_entries |
Posted entries in a period with risk flags (manual, agent, round, weekend, large); the 150 largest when more are flagged. |
entity_code, fiscal_year, period, materiality (optional) |
GET /v1/entities/{entity}/analytics/unusual-entries |
close_checklist |
Period-close checklist (depreciation, FX revaluation, reconciliations, integrity). |
entity_code, fiscal_year, period |
GET /v1/entities/{entity}/periods
GET /v1/periods/{period_id}/close-checklist |
run_period_end |
Run a period-end step: step = 'depreciation', 'fx_revaluation', 'deferred_tax' (after depreciation, for the tax book that carries deferred tax) or 'revenue_recognition' (the revenue contracts' schedule due by the period end, and the presentation of their positions; it may run again and posts only what changed) or 'leases' (the interest and depreciation of the active leases, or an operating lease's lease cost, once per lease and period; a lease whose change of payments waits for approval is skipped and listed in skipped) or 'receivable_allowance' (adjusts the allowance for doubtful receivables to what the open invoices call for at the period end; show receivable_allowance_proposal first). 'fx_revaluation' may also run again after a late posting in the period and posts only what changed. Postings go through the approval policy; say what a step will post and run it once the person agrees. Closing the period itself is a person's act (request_period_close). |
entity_code, fiscal_year, period, step |
GET /v1/entities/{entity}/periods
POST /v1/periods/{period_id}/depreciation
POST /v1/periods/{period_id}/fx-revaluation
POST /v1/periods/{period_id}/deferred-tax
POST /v1/periods/{period_id}/revenue-recognition
POST /v1/periods/{period_id}/leases
POST /v1/periods/{period_id}/receivable-allowance |
close_status_of_period |
Where a period's close stands: each step (recurring invoices, depreciation, FX revaluation, deferred tax, the checklist, the close) and each of the entity's own close tasks with its due day and done, open, overdue or n/a, judged on as_of (ISO date, default today), and the checklist's failing checks. |
entity_code, fiscal_year, period, as_of (optional) |
GET /v1/entities/{entity}/periods
GET /v1/periods/{period_id}/close-status |
close_schedule |
The company's close calendar: who owns the close, the working day after the period end each step is due on, which steps the nightly close job runs, and the company's own close tasks with their owner and day. A person records a task as done (on the period's close page, month_end_close gives the link); you cannot. |
entity_code |
GET /v1/entities/{entity}/close-schedule
GET /v1/entities/{entity}/close-tasks |
year_close_preview |
What closing a fiscal year would post: the result, the closing entry's lines, what prevents a proposal (blockers) and whether can_propose. Stores nothing. A person proposes the close; an agent only reads it. |
entity_code, fiscal_year |
GET /v1/entities/{entity}/fiscal-years/{year}/close-preview |
year_close_status |
Where a fiscal year's close stands: pending (waiting for a second person), closed, reopened or cancelled, its result, what is appropriated and what remains, the approval id to decide, and the resolutions booked. as_of (ISO date, default today) is the day the overdue general meeting is judged on. |
entity_code, fiscal_year, as_of (optional) |
GET /v1/entities/{entity}/fiscal-years/{year}/close |
opening_balances |
The balance sheet a fiscal year opens with (the day before it starts): after a year-end close the profit and loss accounts start at zero and the result is in equity. |
entity_code, fiscal_year |
GET /v1/entities/{entity}/fiscal-years/{year}/opening-balances |
list_appropriations |
The shareholders' resolutions booked against a closed year's result: amount signed like the result, destinations and whether a later reversal cancels it. Optionally only one fiscal year's. |
entity_code, fiscal_year (optional) |
GET /v1/entities/{entity}/appropriations |
unappropriated_years |
The fiscal years whose general meeting is overdue while part of the result is still unappropriated (a Swiss entity, six months after the year end): what the Role Center cue counts. as_of (ISO date) defaults to today. |
entity_code, as_of (optional) |
GET /v1/entities/{entity}/fiscal-years |
list_recurring_journals |
Recurring journals (journal entries that repeat: rent, allocations, accruals), the next to fall due first, with their lines, frequency, status and next due date. due_through (ISO date) keeps those a run through that day would make entries for. Optional entity_code and status (draft, active, paused, ended). |
entity_code (optional), status (optional), due_through (optional), limit (optional) |
GET /v1/recurring-journals |
get_recurring_journal |
One recurring journal: its lines, schedule, whether each entry is reversed in the next period, its status, next due date and how many entries it has made. |
recurring_journal_id |
GET /v1/recurring-journals/{recurring_journal_id} |
recurring_journal_runs |
The periods a recurring journal has made or tried, oldest first: due date, outcome (posted, pending_approval, rejected, failed), the entry and its status now, its reversal, and the error of a failed period. |
recurring_journal_id |
GET /v1/recurring-journals/{recurring_journal_id}/runs |
run_recurring_journals |
Post the entries of the active recurring journals (rent, accruals, allocations) due on or before through (ISO date, at most today), each dated its due date, through the approval policy (posted or pending_approval). Name them and their amounts to the person first (list_recurring_journals with due_through) and run once they agree. Makes nothing twice; more_due says to run again. |
through, idempotency_key, entity_code (optional), recurring_journal_id (optional) |
POST /v1/recurring-journals/run |
asset_register |
Fixed assets with cost, accumulated depreciation and net book value. |
entity_code, as_of |
GET /v1/entities/{entity}/assets |
get_asset |
One fixed asset by code (FA-001, as asset_register lists it) or id: its terms, accounts, source bill and status, and each book it is depreciated in (the accounting book BOOK first) with the position at as_of (ISO date, default today): cost, accumulated depreciation, carrying amount and the schedule. link is its card. |
asset, as_of (optional) |
GET /v1/assets/{asset}
GET /v1/assets/{asset}/books |
register_asset |
Register a fixed asset and get its depreciation schedule. asset: {entity, code? (left out: the company's next number, FA-00001), name, acquisition_date, in_service_date? (default the acquisition date), cost (functional currency), useful_life_years, salvage? (default 0), method? (straight_line | declining_balance | sum_of_years_digits), convention? (pro_rata_months | full_year | half_year | mid_month), cost_account? accumulated_account? expense_account? (default the company's asset accounts), source_document? (the purchase bill that bought it: nothing is posted), post_acquisition? with credit_account (book Dr cost / Cr that clearing account when no bill stands behind it)}. Ask the person for the useful life and the purchase bill (list_documents); never guess them. A posting goes through the approval policy: acquisition_status says whether it is posted or waits. |
asset, idempotency_key |
POST /v1/assets |
dispose_asset |
Dispose of an active asset (scrapped, or sold for cash into proceeds_account, a bank or cash account) on disposal_date (ISO, its period open): books the depreciation due to then, takes cost and accumulated depreciation off and the difference as a gain or loss. Sold to a customer on credit: sell_asset. Your disposal always waits for a person to approve it (status pending_approval); say so, with the gain or loss. |
asset, disposal_date, idempotency_key, proceeds (optional), proceeds_account (optional) |
POST /v1/assets/{asset}/dispose |
sell_asset |
Sell an active asset, or a part of it, to a customer on a sales invoice. sale: {sale_date, customer (code), net_amount (without VAT), currency? (default the customer's), rate_type? (standard | reduced | zero | exempt), description?, percent? | cost? (a part: its share or cost; omitted: the whole asset)}. The invoice carries the VAT the customer's country decides; the asset's gain or loss is against the net amount. Ask the person for the price; never guess it. Your sale always waits for a person: the invoice, then the asset's entry. |
asset, sale, idempotency_key |
POST /v1/assets/{asset}/sale |
list_leases |
The company's leases by code: lessor, currency, commencement and end, payment, status (draft, pending, active, terminated, exempt) and the position at as_of (ISO date, default today): the lease liability (lease currency) and its part due within 12 months, the right-of-use asset's carrying amount (functional currency) and the lease months ended that no period's lease entries booked yet. |
entity_code, as_of (optional) |
GET /v1/entities/{entity}/leases |
get_lease |
One lease (id from list_leases): terms, accounts, changes of payments, the entries that activated and ended it, the schedule month by month (opening, remeasurement, payment, interest, closing liability, depreciation, an operating lease's lease_cost, booked or not) and the position at as_of with the liability split into current and non-current. classification is finance or operating (US GAAP). |
lease_id, as_of (optional) |
GET /v1/leases/{lease} |
create_lease |
Enter a lease the company holds as a lessee, as a draft, and get its schedule. lease: {entity, code? (left out: the company's next number, L-00001), name, lessor?, currency? (default the company's), commencement_date, term_months, payment (each payment), frequency (monthly | quarterly | yearly), timing (advance | arrears), rate_percent (the effective annual rate to discount the payments), classification? (US GAAP: operating | finance), initial_direct_costs?, prepaid?, exemption? (short_term | low_value: only listed, its bills expensed), rou_account?, accumulated_account?, liability_account?, interest_account?, depreciation_account?, lease_cost_account? (default the company's lease accounts)}. Ask the person for the rate and the term from the lease contract; never guess them. Book it with activate_lease. |
lease, idempotency_key |
POST /v1/leases |
activate_lease |
Book a draft lease's commencement entry, dated its commencement date: Dr right-of-use asset / Cr lease liability, and initial direct costs and prepayments from credit_account (needed when it has any). Say what it will post (get_lease) and ask first. It goes through the approval policy: status says whether it is posted or waits for a person. |
lease_id, idempotency_key, credit_account (optional) |
POST /v1/leases/{lease}/activate |
change_lease_payments |
Remeasure an active lease for a new payment from effective_date (the first day of a lease month; e.g. an index increase): the liability becomes the present value of the remaining payments at the original rate and the right-of-use asset changes by the same amount, in one entry through the approval policy. Ask the person for the new payment and the day; never guess them. |
lease_id, effective_date, payment, reason, idempotency_key |
POST /v1/leases/{lease}/changes |
end_lease |
End an active lease early on termination_date (the last day of a lease month, its lease entries booked up to then): the liability left and the right-of-use asset come off, the difference a gain or loss (result_account, default the company's disposal accounts), through the approval policy. Ask the person first. |
lease_id, termination_date, idempotency_key, result_account (optional) |
POST /v1/leases/{lease}/terminate |
unmatched_bank_lines |
Bank statement lines not yet reconciled, each with its best candidate documents and the booked payments it may execute (kind payment: a person links those in the UI or with POST /v1/bank-lines/{line_id}/link; never post them to an account), and for a credit the executed payments it may return (kind return: a person links those too). |
entity_code |
GET /v1/entities/{entity}/bank-lines
GET /v1/bank-lines/{line_id}/candidates |
reconcile_bank_line |
Resolve a bank line: either allocations=[{document, amount, document_amount?}] to settle open documents (amount in the line's currency; document_amount, in the document's currency, for a document in another currency: its open amount when the line pays it in full), or post_to_account='6940' (e.g. bank fees) to book it directly, with the counter line's cost centre, profit centre or project in dimensions ({"cost_centre": "CC-200"}, values from list_dimensions). |
line_id, idempotency_key, allocations (optional), post_to_account (optional), description (optional), dimensions (optional) |
POST /v1/bank-lines/{line_id}/match
POST /v1/bank-lines/{line_id}/post |
bank_reconciliation_status |
A bank account (default: the main one) on a statement date (on, ISO date; default its latest statement's end): the bank's closing balance against the ledger's, the bank items not in the ledger and the ledger items not in the bank, and unexplained, zero when everything is accounted for. done is the record once a person marked it reconciled; that is their act, at link. statement_balance stands in for a statement without a closing balance (a CSV file): ask the person for it. |
entity_code, account (optional), on (optional), statement_balance (optional) |
GET /v1/entities/{entity}/bank-reconciliation |
bank_reconciliation_history |
The reconciliations people marked done, latest statement date first, with who and the balances then (a record that was reset says so). |
entity_code, account (optional), limit (optional) |
GET /v1/entities/{entity}/bank-reconciliations |
propose_vendor_payments |
Which vendor bills to pay (ISO dates): the open bills due by due_until (default the payment date), and with take_discounts those whose cash discount would expire by then, each with the amount after the discount, why it is proposed (overdue, due, cash_discount), its warnings and problems (a missing IBAN, a draft vendor) and whether it is preselected; skipped lists the bills left out and why, bank_balances the bank account each currency is paid from and its balance on the payment date. Stores nothing. Optional vendors (codes), currency, bank_account (GL code). Go through the lines with the person: ask which to pay and whether a balance going below zero is all right before create_payment_run. |
entity_code, payment_date, due_until (optional), take_discounts (optional), vendors (optional), currency (optional), bank_account (optional) |
POST /v1/entities/{entity}/payment-proposals |
create_payment_run |
Make the payments of a proposal the person reviewed, all or none: lines [{document (bill number or id), amount, discount?}] as propose_vendor_payments gave them, one payment per vendor dated payment_date (today at the latest). Each goes through the approval policy (posted or pending_approval). Say first what it will pay, in total per currency, and make it once the person agrees. Nothing reaches the bank: releasing the payment file is the person's act, on the payments page (link). |
entity_code, payment_date, lines, idempotency_key, bank_account (optional) |
POST /v1/entities/{entity}/payment-runs |
payments_to_release |
The posted payments to vendors still to send to the bank in a payment file: ready (nothing stops releasing them) and blocked, each with its problems (a draft vendor, unconfirmed bank details, a missing IBAN) to resolve with the person first. Payments the bank already executed (recorded from a bank line or as paid) are not listed. Read-only: releasing them is the person's act, on the payments page (link). |
entity_code |
GET /v1/payments |
customer_mandates |
A customer's SEPA direct debit mandates, newest signature first: reference, IBAN, scheme (CORE, B2B), status (pending_approval, active, rejected, revoked, expired, used), the sequence of the next collection and a change waiting for a second person. customer is the customer's code or id. Read-only: a person records a mandate the customer signed. |
entity_code, customer |
GET /v1/entities/{entity}/customers/{party}/mandates |
propose_direct_debits |
Which open EUR invoices to collect by direct debit on collection_date (ISO): those of customers with a usable mandate that are due by then or whose cash discount is still open (collected less the discount), with the mandate and sequence each goes under; skipped lists the invoices that cannot be collected on the day and why (no usable mandate, pre-notification too short, not due yet), problems what stops collecting at all. Stores nothing. Optional customers (codes), bank_account (GL code). Go through it with the person and ask which to collect before create_direct_debit_run. |
entity_code, collection_date, customers (optional), bank_account (optional) |
POST /v1/entities/{entity}/direct-debit-proposals |
create_direct_debit_run |
Make the receipts of a collection proposal the person reviewed, all or none: lines [{document (invoice number or id), amount, discount?}] as propose_direct_debits gave them, one receipt per mandate, booked on the payments-in-transit account until the bank statement shows the money, each through the approval policy. Say first what it will collect, from whom and in total, and make it once the person agrees. Nothing reaches the bank: releasing the pain.008 file is the person's act, on the direct debits page (link). |
entity_code, collection_date, lines, idempotency_key, bank_account (optional) |
POST /v1/entities/{entity}/direct-debit-runs |
list_direct_debits |
The receipts collected by direct debit, newest first (at most 200): mandate, scheme, sequence, collection date, whether the bank booked them, the file they went in and problems, what stops releasing one now. sent: false only those not in a file yet, true only those sent; default both. Read-only. |
entity_code, sent (optional) |
GET /v1/entities/{entity}/direct-debits |
exchange_rates |
The ECB exchange rates of a day (date, ISO, default today) against the company's functional currency: 1 currency = rate functional, the inverse, and whether the company uses the currency. The latest fixing on or before the day is used (fallback true on a weekend or holiday). currencies (comma-separated ISO codes, e.g. CHF,EUR,USD, at most 24) instead gives the cross-rate matrix of those, read 1 row = x column. These are the rates the books use; quote them with the fixing date. |
entity_code, date (optional), currencies (optional) |
GET /v1/entities/{entity}/fx/rates
GET /v1/entities/{entity}/fx/matrix |
exchange_rate_history |
The daily ECB rate of a pair (1 base = rate quote) from start to end (ISO dates; default the 30 days to today, at most 1830 days): every fixing, first and last, minimum and maximum with their days, the average and the change, and month: the IAS 21 average and closing rate of the latest completed month in the range (the closing rate is the one the period-end revaluation uses). Good for a chart of a currency over time. |
entity_code, base, quote, start (optional), end (optional) |
GET /v1/entities/{entity}/fx/history |
convert_currency |
An amount (decimal string) in another currency at the ECB rate of the fixing on or before date (ISO, default today), with the rate, its route and the fixing day. It is indicative: a booked amount can differ by one minor unit on an exact tie, and for VAT amounts the official VAT rate applies (vat_exchange_rates), not this one. |
entity_code, amount, from_currency, to_currency, date (optional) |
GET /v1/entities/{entity}/fx/convert |
vat_exchange_rates |
For the company's country, side by side: the accounting rate (ECB, what the books translate at) and the official VAT rate (Switzerland: BAZG; Germany: the BMF monthly rates) the VAT return's foreign-currency amounts use, with the difference. A rate not published yet is provisional; where the country prescribes no official rate supported is false. currencies as in exchange_rates. |
entity_code, date (optional), currencies (optional) |
GET /v1/entities/{entity}/fx/tax-rates |
fx_exposure |
The company's foreign-currency exposure on a day (date, ISO, default today): open receivables, open payables and foreign-currency bank balances by currency, in the currency and in the functional currency at the day's rate against the amount booked, and unrealised, the gain (positive) or loss the period-end FX revaluation would post at that rate. With side (receivables, payables, bank) or currency (ISO code) it lists the positions behind those figures instead (documents and bank accounts, a page of limit from offset). Answers "what would the revaluation book?" before run_period_end step fx_revaluation. |
entity_code, date (optional), side (optional), currency (optional), limit (optional), offset (optional) |
GET /v1/entities/{entity}/fx/exposure
GET /v1/entities/{entity}/fx/exposure/items |
list_dimensions |
What the organization analyses its postings by (cost_centre, profit_centre, project and any it added), each with its values (code, name, the company it is for or every company, the days lines may name it, whether it is active) and, per company, the accounts that require it. A line names values as dimensions: {"cost_centre": "CC-100", "project": "P-17"}. When the person names a cost centre by its name, find its code here; when two could fit, ask which. |
|
GET /v1/dimensions |
dimension_results |
Revenue, expenses and result per value of a dimension (cost_centre, profit_centre, project) for the posted entries dated start to end (ISO dates), with the accounts behind each, in the company's functional currency. Lines that name no value are a row of their own, so the rows add up to the profit and loss of the range: say how much is not assigned when it matters. Year-end closing entries are left out. |
entity_code, dimension, start, end |
GET /v1/entities/{entity}/reports/dimension-balances |
dimension_lines |
The posted profit and loss lines behind a row of dimension_results: those naming value (e.g. CC-100; omitted: the lines that name none), optionally of one account, dated start to end (ISO dates), by date and posting order, with each line's entry and every dimension it names. A posted line's value is not changed: to move an amount to another cost centre, propose a journal entry that moves it (and say what it will post). |
entity_code, dimension, start, end, value (optional), account (optional) |
GET /v1/entities/{entity}/reports/dimension-lines |
analytics_series |
A metric per month, quarter or year over a range (revenue, expenses, net_income, cost_of_sales, operating_expenses, gross_margin_pct, cash, receivables, payables, working_capital, dso, dpo, receivables_aging, payables_aging), optionally split by report_line or account; ties to the reports for the same dates. |
entity_code, metric, start, end, granularity (optional), by (optional) |
GET /v1/entities/{entity}/analytics/series |
analytics_kpis |
Revenue, gross margin, operating expenses, net income, cash, receivables, payables, DSO, DPO and working capital for a range against the previous range or the same dates a year earlier (compare: previous or year_ago). |
entity_code, start, end, compare (optional) |
GET /v1/entities/{entity}/analytics/kpis |
analytics_breakdown |
Top customers by invoiced revenue, vendors by billed spend, sales currencies, or the expense mix (kind: customers, vendors, currency, expense_mix) for a range. |
entity_code, kind, start, end, limit (optional) |
GET /v1/entities/{entity}/analytics/breakdowns |
analytics_insights |
Accounts that moved above materiality against the comparison range, each with a plain sentence, and the entries with risk flags, for any range. |
entity_code, start, end, compare (optional), materiality (optional), limit (optional) |
GET /v1/entities/{entity}/analytics/insights |
list_plans |
Budgets and forecasts, the newest first, each with every version (number, status, totals) and which one is current (approved). Optional entity_code and kind (budget or forecast). |
entity_code (optional), kind (optional) |
GET /v1/plans
GET /v1/plans/{plan_id} |
get_plan_version |
One plan version with every line (account, period YYYY-NN, amount in the functional currency in the account's natural direction, method, note) and its totals. |
version_id |
GET /v1/plan-versions/{version_id} |
plan_comparison |
Plan against actual for each period of a plan version: plan, actual, variance (actual less plan), variance in percent and whether it is good news, by account or report_line, with revenue, expenses and net income added up, and each fiscal year's outlook (closed periods' actuals plus the plan of the rest). Actuals are posted profit and loss by period, closing entries left out; an open period's are not final. With against_version_id (a budget's current version, or an earlier forecast) the variance is this version's amount less that one's. |
version_id, by (optional), against_version_id (optional) |
GET /v1/plan-versions/{version_id}/comparison |
list_opportunities |
The deals of the pipeline, the newest first: customer or prospect, stage, probability, amount and weighted amount, expected close, owner and next step. Optional entity_code, stage (lead, qualified, proposal, negotiation, won, lost), open_only (default: true without a stage, false with one), owner_user_id (list_people) and kind (new_business, expansion, renewal: the renewal deals the subscriptions open). With opportunity_id, that one deal with its timeline (activities). A person who sees only their own or their team's records (and a key of theirs) gets only those deals. |
entity_code (optional), stage (optional), open_only (optional), opportunity_id (optional), owner_user_id (optional), kind (optional) |
GET /v1/opportunities
GET /v1/activities |
opportunity_pipeline |
An entity's pipeline: open deals by stage and currency (count, amount, weighted amount), the deals won and lost this year, and the open and overdue tasks. Amounts are per currency, never converted. |
entity_code |
GET /v1/opportunities/pipeline |
create_opportunity |
Create a deal, or a lead (a deal at the stage lead, the default). opportunity: {entity, title, party? (customer code) | prospect_name (a company that is not a customer yet), prospect_country?, contact_id? (a contact at the customer, list_contacts), contact_name?, contact_email?, contact_phone?, kind? (new_business|expansion|renewal), stage? (lead|qualified|proposal|negotiation), probability? (default by stage: 10, 25, 50, 75), currency? (default: the customer's, else the entity's), amount? (expected net value), expected_close?, owner_user_id? (list_people; default: the person behind this key), source?, next_step?}. It gets the entity's next number (OPP-000001); nothing is posted. |
opportunity, idempotency_key |
POST /v1/opportunities |
update_opportunity |
Change what changes names, the rest keeps its value; "" empties a text field. changes: {title?, party? (the customer, e.g. once a person set the prospect up as one), prospect_name?, prospect_country?, contact_id? ("" clears), contact_name?, contact_email?, contact_phone?, kind?, probability? (an open deal), currency?, amount?, expected_close?, owner_user_id?, source?, next_step?}. The stage moves with move_opportunity_stage. A won deal changes only its owner and next step. Audited with the previous values. |
opportunity_id, changes |
PATCH /v1/opportunities/{opportunity_id} |
move_opportunity_stage |
Move a deal to an open stage (lead, qualified, proposal, negotiation; optional probability), to won (only with an active customer on the deal; final) or to lost (lost_reason required; it can be reopened), with an optional note kept on the timeline. on (ISO date, default today) is the close day of a won or lost deal. |
opportunity_id, stage, idempotency_key, probability (optional), lost_reason (optional), on (optional), note (optional) |
POST /v1/opportunities/{opportunity_id}/stage |
list_people |
The active people of the organization (id, email, name), to name the owner of a deal or the person a task is for. |
|
GET /v1/people |
list_activities |
The timeline of a deal (opportunity_id), a lead (lead_id) or a customer (party_id), newest first, or with open_tasks the tasks not done yet, the earliest due first (optional assignee_user_id). kind: note, call, meeting, email or task; limit at most 1000. |
entity_code (optional), opportunity_id (optional), party_id (optional), kind (optional), open_tasks (optional), assignee_user_id (optional), limit (optional), lead_id (optional) |
GET /v1/activities |
log_activity |
Record a note, call, meeting or e-mail, or plan a task, about a deal, a lead or a customer. activity: {opportunity_id | lead_id | entity + party (customer code), kind (note|call|meeting|email|task), contact_id? (the person it was with, at a customer), subject, body?, occurred_on? (ISO date, default today), due_on? and assignee_user_id? (a task only; default the deal's or the lead's owner), owner_user_id? (who did it; default: the person behind this key)}. An activity is never edited or deleted; a task is done once (complete_task). |
activity, idempotency_key |
POST /v1/activities |
complete_task |
Record that a task is done, by whom and when. Refused for an activity that is not a task or a task already done. |
activity_id |
POST /v1/activities/{activity_id}/complete |
list_leads |
Leads (people who may become customers), the newest first: name, company, e-mail, phone, what they wrote, source (web_form, phone, email, referral, partner, event, advertising, import, other), owner and status (new, working, disqualified, converted). By default only the open ones (new, working); status picks one, unassigned only those nobody owns, q searches name, company, e-mail and number. With entity_code also the counts by status and source (summary). With lead_id, that one lead. |
entity_code (optional), status (optional), open_only (optional), unassigned (optional), q (optional), lead_id (optional) |
GET /v1/leads
GET /v1/leads/{lead_id}
GET /v1/leads/summary |
create_lead |
Add a lead: a person who may become a customer. lead: {entity, last_name, first_name?, company?, role?, email?, phone?, country?, message?, source? (web_form|phone|email| referral|partner|event|advertising|import|other, default other), source_detail? (the campaign or event), owner_user_id? (list_people), email_opt_out?}. It starts new with the company's next number (LEAD-000001). A deal comes from converting it (convert_lead); create_opportunity is for a deal with a known prospect. |
lead, idempotency_key |
POST /v1/leads |
update_lead |
Change what changes names: {status? (new|working|disqualified), disqualified_reason? (needed to disqualify), owner_user_id? ("": nobody), first_name?, last_name?, company?, role?, email?, phone?, country?, message?, source?, source_detail?, email_opt_out?}; "" empties a text field. A converted or erased lead does not change. |
lead_id, changes |
PATCH /v1/leads/{lead_id} |
convert_lead |
Convert a lead in one step into a customer, the person as its contact and a deal. conversion: {party (an existing customer's code; find_records finds it by name) | customer: {code, name? (default: the lead's company), country? (default: the lead's), currency? (default: the company's), business?}, contact_id? (an existing contact of party who is this person), create_deal? (default true), deal_title?, amount?, currency?, stage? (default qualified), expected_close?}. Ask the person which customer it is when it is not clear. The deal is owned by the lead's owner and its first note is what the person wrote. |
lead_id, conversion, idempotency_key |
POST /v1/leads/{lead_id}/convert |
list_quotes |
An entity's quotes, the newest first: number, customer, day, valid until, totals and status (draft, sent, expired, accepted, declined, cancelled; a draft or sent quote past its day is expired). Optional status, customer (code), text (in the number, reference or customer) and limit (at most 1000). |
entity_code, status (optional), customer (optional), text (optional), limit (optional) |
GET /v1/entities/{entity}/quotes |
get_sales_document |
A quote or sales order by number (QT-2026-000001, SO-2026-000001) or id: its lines with VAT, totals, status, the linked quote or order, its invoices, and version (pass it to update_quote to change exactly what you read). |
document |
GET /v1/sales-documents/{document} |
create_quote |
Draft a quote for an active customer, numbered at once (QT-2026-000001). quote: {customer (code), document_date? (default today), valid_until? (default 30 days on), currency? and payment_terms_days? (default the customer's), customer_reference?, notes?, opportunity_id? (the deal it is for, of this customer: its order is for it too), lines: [{product? (code), description? and unit_price? (net; default the product's name and the customer's or list price, required without a product), quantity? (default 1), supply_type? (goods|services|electronic_services), rate_type?, tax_category?, discount_percent? | discount_amount?}], discount_percent? | discount_amount? (on the whole quote)}. Each line gets the VAT an invoice of that day would. The quote stays a draft: a person sends it. |
entity_code, quote, idempotency_key |
POST /v1/entities/{entity}/quotes |
update_quote |
Change a draft quote, or a sent one (it goes back to draft and a person sends it again). changes: {customer?, document_date?, valid_until?, currency?, customer_reference?, payment_terms_days?, notes?, lines? (replaces every line), discount_percent? | discount_amount? (null removes it)}; omitted fields keep their value and every line is priced again. With version (from get_sales_document) a quote someone changed since is refused. |
document, changes, version (optional) |
PATCH /v1/sales-documents/{document} |
sales_pipeline_report |
The open deals of an entity by owner, by stage and by the month they are expected to close: how many, their value and their value weighted by probability, in the entity's functional currency and per deal currency (by_currency); late counts open deals whose expected close has passed. Optional owner_user_id (list_people) and rate_day (ISO, the day of the ECB fixing; default today). For "how is the pipeline", "pipeline by stage" or a chart of expected closes by month. A person who sees only their own or their team's records (and a key of theirs) gets only those deals. |
entity_code, owner_user_id (optional), rate_day (optional) |
GET /v1/sales/pipeline |
sales_win_rate |
The deals won and lost by owner between closed_from (ISO, default 1 January) and closed_to (default today): how many and their value, the win rate by count and by value, the average deal won and the days from creation to close. Ask which period the person means when they do not say. A person who sees only their own or their team's records (and a key of theirs) gets only those deals. |
entity_code, closed_from (optional), closed_to (optional), rate_day (optional) |
GET /v1/sales/win-rate |
sales_activity |
Per person (or agent), from date_from (ISO, default the 1st of this month) to date_to (default today): the calls, meetings, e-mails and notes they logged, the tasks they set and did, the deals they moved to another stage, and the tasks assigned to them that are open and overdue today. |
entity_code, date_from (optional), date_to (optional) |
GET /v1/sales/activity |
sales_forecast |
The forecast against quota, by owner and by month from from_month to to_month (YYYY-MM; default this quarter): the quota, what is won (closed), the open deals expected in the months by forecast category (commit, best case, pipeline), the forecast (closed plus commit), the best case, attainment and the gap to the quota. Deals expected before the months (late) or without a close date (undated) are counted, not summed: say so when there are any. A person who sees only their own or their team's records (and a key of theirs) gets only those deals. |
entity_code, from_month (optional), to_month (optional), rate_day (optional) |
GET /v1/sales/forecast |
list_sales_quotas |
Each person's quota per month of a calendar year (default this year), in the entity's functional currency. Quotas are set by a manager in the app, never by a tool. |
entity_code, year (optional) |
GET /v1/sales/quotas |
list_contacts |
The people at customers and vendors, by last and first name: name, role, e-mail, phones, language, whether they want sales e-mails (email_opt_out), the organization's own fields (custom). Optional entity_code, party_id (one customer's or vendor's people), text (in the name, e-mail or role), email (exact, any case) and limit (at most 1000). With contact_id, that one contact. Look a person up here before adding them, so nobody is entered twice. |
entity_code (optional), party_id (optional), text (optional), email (optional), contact_id (optional), limit (optional) |
GET /v1/contacts
GET /v1/contacts/{contact_id} |
list_custom_fields |
The organization's own fields on companies (customers and vendors), contacts and deals (record: company, contact or deal), in their order: key, label, type and choices. A record's values are in its custom, by key. |
record (optional) |
GET /v1/custom-fields |
create_contact |
Add a person at a customer or vendor. contact: {entity, party (code), kind? (customer|vendor, when a code is both), last_name, first_name?, role?, email?, phone?, mobile?, language? (de|fr|it|en|rm), email_opt_out? (true: no sales e-mails), custom? ({key: value} of the organization's contact fields, list_custom_fields)}. Name the contact on a deal or an activity by its id (contact_id). |
contact, idempotency_key |
POST /v1/contacts |
update_contact |
Change what changes names, the rest keeps its value: {first_name?, last_name?, role?, email?, phone?, mobile?, language?, email_opt_out?, custom? (only the keys sent change)}; "" clears a text field but the last name. A contact never moves to another customer or vendor (add one there instead). Refused for an erased contact. |
contact_id, changes |
PATCH /v1/contacts/{contact_id} |
list_products |
What the entities sell, by code: kind (recurring per month or year, or one-off per unit), unit, revenue account, supply and VAT rate type, every list price and standalone selling price. Optional entity_code and active_only (default true). With currency, each product also carries in_force: the list price and SSP in force on on (YYYY-MM-DD, default today), what an invoice line of it proposes. |
entity_code (optional), active_only (optional), currency (optional), on (optional) |
GET /v1/products
GET /v1/products/{product_id}/price |
list_price_lists |
The price lists by code: currency, active, every price (product, unit price, period for a recurring product, the minimum quantity of its volume tier, the first day) and the customers that take it. Optional entity_code and active_only (default true). With entity_code and customer_code, also customer: the list that customer takes in each currency. A line of a product for the customer proposes the price of the highest tier at or below its quantity, that tier's latest from on or before the day. |
entity_code (optional), active_only (optional), customer_code (optional) |
GET /v1/price-lists
GET /v1/entities/{entity}/customers/{party}/price-lists |
list_recurring_invoices |
Recurring invoices (templates of invoices that repeat), the next to fall due first, with their terms, status and next due date. due_through (ISO date) keeps those a run through that day would make invoices for: what the Role Center cue recurring_due counts. Optional entity_code and status (draft, pending_approval, active, paused, ended). |
entity_code (optional), status (optional), due_through (optional), limit (optional) |
GET /v1/recurring-invoices |
get_recurring_invoice |
One recurring invoice: its terms, status, next due date, whether its current terms are the approved ones, the pending approval and how many invoices it has made. |
template_id |
GET /v1/recurring-invoices/{template_id} |
recurring_invoice_runs |
The periods a recurring invoice has made or tried, oldest first: due date, outcome (drafted, posted, pending_approval, failed), the invoice and its status now, and the error of a failed period. |
template_id |
GET /v1/recurring-invoices/{template_id}/runs |
run_recurring_invoices |
Make the invoices of the active recurring invoices due on or before through (ISO date, at most today), dated their due date: a draft for a person to submit, or submitted through the approval policy where the template says so. Name them and their amounts to the person first (list_recurring_invoices) and run once they agree. Makes nothing twice; more_due says to run again. |
through, idempotency_key, entity_code (optional), recurring_invoice_id (optional) |
POST /v1/recurring-invoices/run |
list_revenue_contracts |
Revenue contracts (IFRS 15), the newest first: customer, period, transaction price, status and the performance obligations with their SSP and, once active, their allocated price. Optional entity_code and status (draft, pending_approval, active, completed, cancelled); limit at most 1000; with_schedule adds each contract's recognition schedule; link opens each for the person. Activating a contract and satisfying an obligation are the person's decisions, so no tool does either. |
entity_code (optional), status (optional), with_schedule (optional), limit (optional) |
GET /v1/revenue-contracts
GET /v1/revenue-contracts/{contract_id}/schedule |
preview_revenue_recognition |
What the period's revenue recognition run would post now, without posting: per obligation the revenue due by the period end, and the contracts whose debit position (recognised, not yet billed) is to be presented as a contract asset or an unbilled receivable. Run it with run_period_end (step revenue_recognition). |
entity_code, fiscal_year, period |
GET /v1/entities/{entity}/periods
GET /v1/periods/{period_id}/revenue-recognition/preview |
create_revenue_contract |
Draft a revenue contract (IFRS 15) for an active customer. contract: {entity, party (customer code), title, start_date, end_date, currency? (default the company's), transaction_price (net of VAT), right_to_consideration? (conditional | unconditional), obligations: [{description, product? (code: its SSP on the start day) or ssp with ssp_basis (how it was established), pattern (over_time | point_in_time), method? (straight_line | monthly), service_start?, service_end?, quantity?, revenue_account?}]}. Ask the person for the price and what was promised; never guess an SSP. Nothing is allocated or booked until the person asks for the terms to be approved and a second person approves them: give the person link. |
contract, idempotency_key |
POST /v1/revenue-contracts |
preview_revenue_contract_change |
What ending an active contract early or modifying it would do, from what is posted now; nothing is written. change: {kind (end | modify), end_date? (end: the last day; modify: a new last day), price? (the new transaction price), effective_date? (modify), reason}. Show the person the amounts; asking for the change is theirs, on the contract (link), and a second person approves it. |
contract_id, change |
POST /v1/revenue-contracts/{contract_id}/changes/preview |
list_subscriptions |
Subscriptions, the newest first: customer, term, how they are billed, the term's amount, the next period to bill, status and the lines with their monthly amounts and obligations. Optional entity_code and status (draft, pending_approval, active, cancelled, ended); limit at most 1000; with_invoices adds the billed periods. link opens each for the person. Approving the terms is a second person's decision, so no tool does it. |
entity_code (optional), status (optional), with_invoices (optional), limit (optional) |
GET /v1/subscriptions
GET /v1/subscriptions/{subscription_id}/invoices |
create_subscription |
Draft a subscription for an active customer. subscription: {entity, party (customer code), title, start_date, term_months (whole billing periods), billing_frequency (monthly | quarterly | yearly), billing_timing (advance | arrears), currency? (default the won deal's, else the customer's), auto_renew?, renewal_notice_days?, renewal_uplift_percent?, payment_terms_days?, opportunity? (the won deal's id), lines: [{product (a recurring product's code), quantity, unit_price? (default its list price), discount_percent?, description?}]}. Ask the person for the term, the billing and any discount; never guess them. Nothing is billed until the person asks for the terms to be approved and a second person approves them: give the person link. |
subscription, idempotency_key |
POST /v1/subscriptions |
preview_subscription_change |
What an amendment of an active subscription would do, from what is posted now; nothing is written. amendment: {kind (change | cancel | renew), reason, and for change (a new plan: an upgrade or a downgrade) effective_date and lines (every line from that day, as create_subscription takes them), for cancel end_date (the last day of service) and proration? (prorate | none)}. Gives the new price, the credits on invoices already made and, for a change, the first charge of the new lines. Show the person the amounts; asking for it is theirs, on the subscription (link), and a second person approves it. |
subscription_id, amendment |
POST /v1/subscriptions/{subscription_id}/amendments/preview |
recurring_revenue |
Monthly recurring revenue (MRR) and ARR (12 x MRR) at each month's end from from_month to to_month (YYYY-MM; default the last 12 months up to the current one, at most 36, none to come), read from the subscription lines in force, never from the ledger. Each month explains the change with each customer's movement (new, expansion, contraction, churn, reactivation, naming the subscriptions) and gives the customer churn rate, the gross MRR churn rate and the net MRR retention; amounts are in the entity's functional currency (each month at its ECB fixing, the change of rates in currency_effect) and per subscription currency. For "MRR trend", "churn this year" or a chart of ARR by month; the renewal deals are list_opportunities with kind renewal. |
entity_code, from_month (optional), to_month (optional) |
GET /v1/subscriptions/metrics |
list_support_cases |
The support cases to work on, the next one due first: number, subject, status, priority, customer, contact or requester, the person working it, and its service levels (first_response and resolution: due_at, state running|paused|met|breached, minutes_left). Optional entity_code, queue (code, with entity_code), show (active: open and waiting, the default; open; waiting; closed; all), unassigned and breached. With case_id, that one case with its messages (the customer's, replies, notes, drafts), the addresses a reply may go to, and its link for the person. |
entity_code (optional), queue (optional), show (optional), unassigned (optional), breached (optional), case_id (optional) |
GET /v1/support/cases
GET /v1/support/cases/{case_id} |
list_support_queues |
The support queues: code, inbox address, service levels per priority (working minutes to the first reply and to the resolution), working hours, members and open cases. |
entity_code (optional) |
GET /v1/support/queues |
open_support_case |
Open a case for what a customer asked (a call, a chat, a request the person passes on). case: {entity, queue (code), subject, description (what the customer asked, as they said it), channel? (phone|email|web|other, default phone), priority? (low|normal|high| urgent, default normal), party? (customer code), contact_id? (GET /v1/contacts), requester_name?, requester_email?, assignee_user_id? (list_people; none: the queue assigns)}. It gets the company's next number (CASE-000001) and its service levels. |
case, idempotency_key |
POST /v1/support/cases |
triage_support_case |
Triage a case: changes: {subject?, queue? (code), priority? (low|normal|high|urgent), assignee_user_id? (list_people), party? (customer code), contact_id?, requester_name?, requester_email?}; null clears the person, customer, contact or requester. A new queue or priority sets its due times anew. The status is the person's: say what you suggest and give them the link. |
case_id, changes |
PATCH /v1/support/cases/{case_id} |
add_case_note |
An internal note on the case for colleagues (what you found, what to check); it is never sent to the customer. |
case_id, body |
POST /v1/support/cases/{case_id}/notes |
draft_case_reply |
Draft a reply to the customer, in their language, signed by nobody (the system adds the company and case number). It is kept as a draft: a person reads it on the case (link), changes it if need be and sends it; you never send. to: the requester's, the contact's or the customer's addresses (default: the requester). |
case_id, body, to (optional) |
POST /v1/support/cases/{case_id}/replies |
list_periods |
The company's posting periods (months, mostly) with their number, dates and status (open or closed), of one fiscal_year or the ones containing the day on (ISO date). Use it to find which period the person means ("close September" is the period whose dates are in September) before any close tool; when it is not clear which company or month, ask. |
entity_code, fiscal_year (optional), on (optional) |
GET /v1/entities/{entity}/periods |
month_end_close |
Start and continue a month-end close here. For the period (period: its number in the fiscal_year, from list_periods): what is still open, in order (next): each failing or warning close check, each VAT return not filed and each bank account not yet marked reconciled, with who acts (who: assistant, person or both), the tools to use, what to ask the person, what only the person does and the link where they do it in one click. close is the request to close: ready or not, what blocks it and the person's link. how says how to work with the person. Reads only; call it again after each step. |
entity_code, fiscal_year, period |
GET /v1/entities/{entity}/periods
GET /v1/periods/{period_id}/close-checklist
GET /v1/entities/{entity}/vat-periods
GET /v1/entities/{entity}/bank-reconciliation |
request_period_close |
Ask the person to close the period. You cannot close a period yourself: closing locks it and is a person's act. This checks the close checklist and returns link, the page where the person closes it with one click, and say, what to tell them; when ready is false, blocked_by names the failing checks to finish first (month_end_close says how). Changes nothing. |
entity_code, fiscal_year, period |
GET /v1/periods/{period_id}/close-checklist |
review_close |
Write the period's close memo, the record the close keeps of its review: the server's close-review agent reads the checklist, the variances against the prior period, the unusual entries and the subledger ties and records the issues (blocker, warning, info). It posts nothing. Do it once the open items are done, show the person the memo and the issues, and ask about each blocker. materiality (functional currency) is the amount above which a variance is flagged. |
entity_code, fiscal_year, period, idempotency_key, materiality (optional) |
POST /v1/agents/periods/{period_id}/close-review |
vat_report |
VAT by jurisdiction, treatment and rate for a period, reconciled to the ledger. |
entity_code, start, end |
GET /v1/entities/{entity}/reports/vat |
vat_periods |
The company's VAT return periods of a calendar year (months, quarters, half years or the year, by its VAT settings, independent of the fiscal calendar): each with its live return (return_id, status: open when none is computed yet), the amount payable, when it is due to be filed and paid (due_date, due_status: filed, upcoming, due_soon, overdue) and whether it was submitted (filing_status). |
entity_code, year |
GET /v1/entities/{entity}/vat-periods |
list_vat_returns |
VAT returns, newest period first, without their boxes: period, status (draft, pending_approval, final, amending, superseded, discarded), amount payable and the number of errors and warnings. Optional entity_code, status, year. |
entity_code (optional), status (optional), year (optional) |
GET /v1/vat-returns |
get_vat_return |
A VAT return with its boxes (Ziffer, Kennzahl or box number and amount), the reconciliation with the VAT accounts, the issues (errors block finalising) and the hand-entered adjustments; link is its page for the person. |
return_id |
GET /v1/vat-returns/{return_id} |
vat_box_lines |
The journal lines behind one box of a return (its boxes[].id), with entry, account, document, counterparty and amount: what to show when the person asks where a figure comes from. |
return_id, box |
GET /v1/vat-returns/{return_id}/boxes/{box}/lines |
prepare_vat_return |
Compute a draft VAT return from the posted ledger for period (2026-09, 2026-Q3, 2026-H2 or 2026, as vat_periods names it); a draft of the period is recomputed. kind: vat_return (default), recapitulative_statement or annual_summary. adjustments [{box, amount, account?, note?}] are amounts only the person knows for boxes the ledger does not fill (import VAT paid to customs and the like): ask for them, never guess. Go through the boxes and the issues with the person. Finalising the return, submitting it and recording the submission and the payment are the person's acts, on the return's page (link). |
entity_code, period, idempotency_key, kind (optional), adjustments (optional) |
POST /v1/vat-returns |
recompute_vat_return |
Recompute a draft VAT return from the ledger as it is now (after a late posting or a correction), replacing its adjustments when adjustments is given (omit it to keep them). |
return_id, idempotency_key, adjustments (optional) |
POST /v1/vat-returns/{return_id}/recompute |
discard_vat_return |
Discard a draft VAT return (it stays listed as discarded; the period can be computed again). Only when the person asks for it. |
return_id, idempotency_key |
POST /v1/vat-returns/{return_id}/discard |
withholding_tax_codes |
The withholding tax codes of the company's country a vendor can carry (Germany Paragraph 50a EStG, Italy ritenuta d'acconto, Spain IRPF, the US NRA and backup withholding, and others), each with its rate and whom it is paid to, and the account bills book the tax on. Read-only. |
entity_code |
GET /v1/entities/{entity}/withholding-tax/codes |
withholding_tax_report |
The withholding tax kept back from vendors from start to end (ISO dates), to file and pay it: per posted bill and vendor credit note the vendor, the net the tax was taken on, the rate, the tax in the document and the functional currency and the code with whom it is paid to; totals per code and currency. basis: bill_date (default, the bills dated in the period as booked) or payment_date (the part released by payments made in the period, for authorities owed the tax when the vendor is paid): ask the person which their authority uses when you do not know. Read-only; filing and paying the authority are the person's (link is the report). |
entity_code, start, end, basis (optional) |
GET /v1/entities/{entity}/withholding-tax |
sales_tax_setup |
A US company's sales tax setup: the states it is registered in (with each state's liability account and what it owes now), its jurisdictions and their rates in force on on (ISO date, default today), its tax areas with their combined rates and the product taxability per state. applies is false for a company outside the US, which charges VAT. Read-only. |
entity_code, on (optional) |
GET /v1/entities/{entity}/sales-tax |
sales_tax_periods |
Each state registration's return periods of a calendar year that have started, with the tax from the ledger, the day each return is due and its state (open, to_file, due_soon, overdue, awaiting_approval, filed, paid), and the year's sales into states the company is not registered in (where it may owe registration). Read-only. |
entity_code, year |
GET /v1/entities/{entity}/sales-tax/periods |
sales_tax_return |
A state's sales tax return (state like US-CA; period 2026-08, 2026-Q3 or 2026 by the state's filing frequency, as sales_tax_periods names it) from the posted ledger: gross, exempt and taxable sales, the tax by jurisdiction, the check against the state's account (unexplained_difference is zero when they agree) and the filing with its payments when recorded. Go through the figures with the person and explain any difference before they file. Read-only: filing with the state, recording it as filed (a second person approves the record) and linking the payment are the person's acts, on the return's page (link). |
entity_code, state, period |
GET /v1/entities/{entity}/sales-tax/returns/{state}/{period} |
customer_sales_tax |
A customer's state, tax area and exemption certificate, and whether the certificate is valid today. customer is the customer's code or id. Read-only. |
entity_code, customer |
GET /v1/entities/{entity}/customers/{party}/sales-tax |
sales_tax_payment_candidates |
The posted entries that may have paid a filed sales tax return (filing.id of sales_tax_return): dated after the period, with a debit on the state's account that is no sales tax posting and not linked to a return yet, typically the bank entry of the state's debit. Read-only: linking the payment is the person's act, on the return's page. |
sales_tax_return_id |
GET /v1/sales-tax-returns/{sales_tax_return_id}/payment-candidates |
list_purchase_orders |
An entity's purchase orders, the newest first: number, vendor, dates, net total, status (draft, pending_approval, open, partially_received, partially_invoiced, closed, cancelled) and version. Optional status (one or more), vendor (code), text (in the number, buyer reference or vendor), start/end (order date, YYYY-MM-DD) and limit (at most 1000). |
entity_code, status (optional), vendor (optional), text (optional), start (optional), end (optional), limit (optional) |
GET /v1/entities/{entity}/purchase-orders |
get_purchase_order |
A purchase order by number (PO-2026-000001) or id: its lines with the ordered, received and invoiced quantities, the receipts, the bills matched to it, who approved it (or refused it, and why), version (pass it to change exactly what you read), link (its page) and, when something is the person's to do, person. |
order |
GET /v1/purchase-orders/{order} |
purchase_order_history |
What happened to a purchase order, oldest first: changes, submission, approval or refusal, receipts, cancelling and closing, each with who and when. |
order |
GET /v1/purchase-orders/{order}/history |
create_purchase_order |
Draft a purchase order for an active vendor, numbered at once (PO-2026-000001). order: {vendor (code), order_date? (default today), expected_date?, currency? and payment_terms_days? (default the vendor's), buyer_reference?, notes?, delivery_address? {name?, street?, building_number?, postal_code?, town?, country?} (omit for the company's own), lines: [{description, quantity, unit_price (expected net), line_type? (goods|services), account? (expense or asset code), item? (code of a stock item: the line is goods and what arrives enters stock), rate_type?, tax_category?, requires_receipt? (default goods yes, services no: the bill is matched against what arrived)}]}. Ask the person for what you do not know (vendor, quantities, prices); never guess a price. Nothing is posted; the order stays a draft until submitted. |
entity_code, order, idempotency_key |
POST /v1/entities/{entity}/purchase-orders |
update_purchase_order |
Change a draft purchase order (also one a second person refused). changes: {vendor?, order_date?, expected_date?, currency?, buyer_reference?, payment_terms_days?, delivery_address?, notes?, lines? (replaces every line)}; omitted fields keep their value. A submitted order is refused. With version (from get_purchase_order) an order someone changed since is refused. |
order, changes, version (optional) |
PATCH /v1/purchase-orders/{order} |
submit_purchase_order |
Submit a draft purchase order for approval; confirm with the person first (vendor, lines, total). It becomes pending_approval and a second person approves or refuses it on Approvals (approvals_link). You never approve an order. |
order, version (optional) |
POST /v1/purchase-orders/{order}/submit |
cancel_purchase_order |
Cancel a purchase order on which nothing was received or invoiced, with the reason the person gives (a pending approval request is withdrawn). It cannot be undone: ask the person first. |
order, reason, idempotency_key, version (optional) |
POST /v1/purchase-orders/{order}/cancel |
close_purchase_order |
Close an approved order for the rest (short close), with the reason the person gives: what was received or invoiced stays, the rest of each line is closed. Later receipts beyond it are refused, and a bill beyond it is blocked for payment. It cannot be undone: ask the person first. |
order, reason, idempotency_key, version (optional) |
POST /v1/purchase-orders/{order}/close |
get_bill_match |
How a purchase bill matches the purchase order its order_reference names: per line, the order line, the price and quantity variances (2-way or 3-way against what arrived), the tolerance, status (matched, variance, unmatched) and whether the bill is blocked for payment (payment_block, with person saying what clears it). Refused when the bill was never matched. |
document_id |
GET /v1/documents/{document_id}/match |
match_bill |
Match a purchase bill to its order again, e.g. after the person recorded a receipt (bills are matched when submitted). An approved variance stays approved. Safe to repeat. |
document_id |
POST /v1/documents/{document_id}/match |
purchase_settings |
The entity's matching tolerances: a bill line may differ from its order line by tolerance_percent of the expected amount and at most tolerance_amount. |
entity_code |
GET /v1/entities/{entity}/purchase-settings |
list_warehouses |
Where the entities keep stock, by entity and code: address, whether it is the default and active, and how many items it holds. Optional entity_code and active. |
entity_code (optional), active (optional) |
GET /v1/warehouses |
create_warehouse |
Add a warehouse. warehouse: {entity, code? (never changed; made from the name), name, address? {street?, building_number?, postal_code?, town?, country?}, is_default?}. The entity's first one is its default and adds the inventory accounts its chart names when they are missing (which needs the right to manage accounts). Nothing is posted. |
warehouse, idempotency_key |
POST /v1/warehouses |
update_warehouse |
Change a warehouse (by code): changes: {name?, address?, is_default? (true makes it the default), active?}. The default warehouse, or one that holds stock, cannot be made inactive. |
entity_code, warehouse, changes |
PATCH /v1/warehouses/{warehouse_id} |
create_stock_item |
Start keeping a product in stock (goods sold per unit, see list_products). item: {product (code), entity, inventory_account? and cogs_account? (codes; default the entity's accounts for inventory and cost of goods sold)}. Nothing is posted; opening stock is an adjustment (adjust_stock). |
item, idempotency_key |
POST /v1/stock-items |
update_stock_item |
Change a stock item's accounts (by product code): changes: {cogs_account?, inventory_account? (only while nothing is in stock)}. |
entity_code, item, changes |
PATCH /v1/stock-items/{product_id} |
list_stock_items |
The products kept in stock, by code: the quantity in each warehouse, the value and the moving average cost, in the entity's functional currency. Optional entity_code, item (one product code; needs entity_code), in_stock (true: only those in stock; false: only those not) and limit (at most 5000). |
entity_code (optional), item (optional), in_stock (optional), limit (optional) |
GET /v1/stock-items
GET /v1/stock-items/{product_id} |
stock_valuation |
Each item's quantity and value at moving average at the end of a day (as_of, YYYY-MM-DD, default today), the total, and the balance of the inventory accounts in the ledger it ties to (a difference is worth raising with the person). Optional warehouse (code): only its quantities. |
entity_code, as_of (optional), warehouse (optional) |
GET /v1/entities/{entity}/stock-valuation |
list_stock_postings |
Every change of an entity's stock, the newest first, with its movements (item, warehouse, quantity, value), its journal entry and the document behind it. Optional kind (receipt, delivery, return, transfer, adjustment, count, revaluation), status (posted, pending_approval, rejected), item and warehouse (codes), start/end (posting day, YYYY-MM-DD) and limit (at most 1000). |
entity_code, kind (optional), status (optional), item (optional), warehouse (optional), start (optional), end (optional), limit (optional) |
GET /v1/stock-postings
GET /v1/stock-postings/{posting_id} |
adjust_stock |
Book goods in or out without a document: damaged, lost or found goods, opening stock. adjustment: {entity, posting_date? (default today, in an open period), reason (shown on the entry), offset_account? (default the inventory adjustment account; opening stock names the opening balance account), lines: [{item (code), warehouse? (code, default the default one), quantity (positive in, negative out), unit_cost? (of goods coming in; default the moving average)}]}. Ask the person for the reason, the quantities and, for goods coming in, the cost; never guess them. Your adjustment waits for a person. |
adjustment, idempotency_key |
POST /v1/stock-adjustments |
transfer_stock |
Move goods between two warehouses of an entity. transfer: {entity, from_warehouse, to_warehouse (codes), posting_date? (default today), note?, lines: [{item (code), quantity (above 0)}]}. The value stays with the entity, so nothing is posted to the ledger. Refused when the warehouse the goods leave does not hold them. |
transfer, idempotency_key |
POST /v1/stock-transfers |
list_stock_counts |
Stock counts, the newest first: warehouse, day, status (open, posted, cancelled) and each line's book and counted quantity with the difference in value. Optional entity_code, status, count_id (just that count) and limit (at most 1000). |
entity_code (optional), status (optional), count_id (optional), limit (optional) |
GET /v1/stock-counts
GET /v1/stock-counts/{count_id} |
open_stock_count |
Open a count of a warehouse. count: {entity, warehouse (code), count_date? (default today, not in the future), note?, items? (product codes; default every active stock item)}. One count of a warehouse is open at a time. Then ask the person what they counted of each line. |
count, idempotency_key |
POST /v1/stock-counts |
enter_stock_count |
Record what the person counted: lines: [{item (code), counted_quantity (null clears it)}]. Only the quantities the person gave you; never fill in the book quantity for a line they did not count. |
count_id, lines |
PUT /v1/stock-counts/{count_id}/lines |
post_stock_count |
Book the differences of a count whose every line is counted, at the moving average, against the inventory adjustment account. Tell the person the differences and their value first. Your posting waits for a person (see person). Refused once goods moved in the warehouse after the count's day (cancel and count again). |
count_id, idempotency_key |
POST /v1/stock-counts/{count_id}/post |
cancel_stock_count |
Cancel an open count; nothing is posted. |
count_id |
POST /v1/stock-counts/{count_id}/cancel |
list_delivery_notes |
Delivery notes, the newest delivery first, with their lines, the cost the goods left with and what is left to invoice. Optional entity_code, status (draft, pending_approval, posted, cancelled), customer (code, needs entity_code), text (in the number, reference or customer), start/end (delivery day, YYYY-MM-DD) and limit (at most 1000). |
entity_code (optional), status (optional), customer (optional), text (optional), start (optional), end (optional), limit (optional) |
GET /v1/delivery-notes |
get_delivery_note |
A delivery note by number (DN-2026-000001) or id: its lines with the cost each line's goods left with, what was invoiced, what came back and what is left to invoice, its version (pass it to change exactly what you read) and link (its page). |
note |
GET /v1/delivery-notes/{note} |
delivered_not_invoiced |
Every line of a posted delivery note with goods delivered and not yet invoiced, oldest first, with what is left at the cost it left with: the revenue still to invoice (invoice_delivery_note drafts its invoice). Optional customer (code). |
entity_code, customer (optional) |
GET /v1/entities/{entity}/delivered-not-invoiced |
create_delivery_note |
Draft a delivery note of stock items to a customer. note: {entity, customer (code), warehouse? (code, default the default one), delivery_date? (default today), customer_reference?, notes? (printed), lines: [{item (stock item code), quantity, description?, sales_line? (id of the sales order line it delivers, from get_sales_document)}]}. A line of an order beyond what is left to ship is refused. Nothing moves until it is posted. |
note, idempotency_key |
POST /v1/delivery-notes |
update_delivery_note |
Change a draft delivery note. changes: {customer?, warehouse?, delivery_date?, customer_reference?, notes?, lines? (replaces every line)}; omitted fields keep their value. With version (from get_delivery_note) a note someone changed since is refused. |
note, changes, version (optional) |
PATCH /v1/delivery-notes/{note} |
post_delivery_note |
Post a draft delivery note: it is numbered and its goods leave stock on the delivery day, Dr cost of goods sold / Cr inventory at the moving average. Say what it ships and ask the person first. When the approval policy holds it, it is pending_approval (see person). Refused when the warehouse does not hold the goods on that day. |
note |
POST /v1/delivery-notes/{note}/post |
cancel_delivery_note |
Cancel a draft delivery note: it stays, moves nothing and no longer counts against its order. A posted note is corrected with a credit note that takes the goods back, or a stock adjustment. |
note |
POST /v1/delivery-notes/{note}/cancel |
invoice_delivery_note |
Draft the sales invoice of what a posted delivery note delivered and is not yet invoiced, at the sales order's prices (a line without an order takes the product's list price in the customer's currency). Optional document_date (YYYY-MM-DD, default today). Answers the draft invoice, which is checked, posted and sent like any other. |
note, idempotency_key, document_date (optional) |
POST /v1/delivery-notes/{note}/invoice |
list_notifications |
The notification centre of the person behind this key, the newest first: tasks given to them, due or overdue, deals of theirs assigned, won or lost by someone else, their approval requests decided. unread counts the unread ones and approvals_waiting the approval requests the person may decide now (list_pending_approvals lists them). Each item is a kind with its values (params) and a link into the app. For "what waits for me" or "what happened on my deals"; nothing is marked read. limit 1 to 200. |
unread_only (optional), limit (optional) |
GET /v1/me/notifications |
autopilot_status |
What Autopilot keeps true for the company by itself: each outcome (e.g. bank_matched: every bank line up to today matched, booked or set aside), whether it is on and for whom, its state after the latest pass (on_track, open, waiting for a person, problem), the items still open, the steps that pass left a person (handoffs, each with its path in the app), the open questions the AI asked, and the day's AI budget used. For "what did the system do" and "what waits for me". |
entity_code |
GET /v1/entities/{entity}/autopilot |
autopilot_passes |
Autopilot's passes of the company, newest first (at most 50; of one outcome if given), each with what started it, for whom it acted, what was open before and after and how much the rules and the AI settled; with pass_id, that pass step by step: each item the AI worked on, the tools it called, whether the outcome's own check found it settled, and what it asked. |
entity_code, outcome (optional), pass_id (optional) |
GET /v1/entities/{entity}/autopilot/passes
GET /v1/autopilot/passes/{pass_id} |
code_bill |
Code a draft purchase bill or vendor credit note and submit it. lines: [{line_no, account? (expense or asset code), dimensions? ({"cost_centre": "CC-100"}, values from list_dimensions)}] change only those lines; amounts, dates and VAT stay as the bill says. order_reference: the purchase order number the bill is for ("" clears it); it is matched on submit (see get_bill_match). The response says whether the bill posted or waits for approval; link is its page. |
document_id, idempotency_key, lines (optional), order_reference (optional) |
PATCH /v1/documents/{document_id}
POST /v1/documents/{document_id}/submit |
list_capacity_items |
What is sold by the time slot, by entity and product code: the slot (night, day or hour), the units in each slot and what is booked and free today. Optional entity_code and item (one product code; needs entity_code). |
entity_code (optional), item (optional) |
GET /v1/capacity-items
GET /v1/capacity-items/{product_id} |
capacity_availability |
What is free of an item (by product code) on each day: its units, the units booked and the units free (for a night, the night that starts that day). first_day (YYYY-MM-DD, default today) to last_day (included, default 13 days later), at most a year. |
entity_code, item, first_day (optional), last_day (optional) |
GET /v1/capacity-items/{product_id}/availability |
create_capacity_item |
Make a product bookable by the time slot (sold per unit and not goods, see list_products). item: {product (code), entity, slot (night: a room; day: a meeting room or a person's day; hour: people's time in hours a day; never changed), units (how many in each slot, e.g. 12 rooms or 24 hours a day of three people)}. Nothing is posted. |
item, idempotency_key |
POST /v1/capacity-items |
update_capacity_item |
Set how many units an item (by product code) has in each slot. Refused below what is booked on a day from today on: the answer names the day. |
entity_code, item, units |
PATCH /v1/capacity-items/{product_id} |
list_capacity_bookings |
Bookings by first day and number, with their item, customer, days and units. Optional entity_code, item (product code) or number (BK-...), both needing entity_code; status (booked or cancelled); first_day and last_day (YYYY-MM-DD: only those that cover a day of the span); limit (at most 5000). |
entity_code (optional), item (optional), number (optional), status (optional), first_day (optional), last_day (optional), limit (optional) |
GET /v1/capacity-bookings
GET /v1/capacity-bookings/{booking_id} |
book_capacity |
Book units of an item in every slot from the first to the last day, both included: booking: {entity, item (product code), customer? (code), first_day, last_day (YYYY-MM-DD; a stay that leaves on the 5th books the nights up to the 4th), quantity (rooms, seats or people a slot, or hours a day), reference?, note?}. Refused when a day has fewer units free than asked for (capacity_availability shows them). Nothing is posted. |
booking, idempotency_key |
POST /v1/capacity-bookings |
cancel_capacity_booking |
Cancel a booking (by number, BK-...), which frees its units. Refused when it is cancelled already, and when a module keeps it (held_by: a hotel stay's rooms are cancelled with the stay, cancel_stay). |
entity_code, number |
POST /v1/capacity-bookings/{booking_id}/cancel |
list_intercompany_relationships |
The approved relationships between two entities of the organization: terms (mirror mode, tolerance, VAT group, the transfer-pricing record), who requested and approved them, the approval that waits, the group parties, and the counts of mirrors to accept, not made and rejected. Optionally only one state or one entity's. |
status (optional), entity_code (optional) |
GET /v1/ic/relationships |
list_intercompany_links |
The documents an invoice or credit note of one entity created in the other, newest first: drafted waits for a person in the receiving entity to accept it (not the one who posted the origin), pending could not be made (error says why). Optionally only one status, relationship (id) or entity. |
status (optional), relationship_id (optional), entity_code (optional), limit (optional) |
GET /v1/ic/links |
intercompany_reconciliation |
Whether the two sides of each relationship agree as of a day (ISO date), in the document currency: the open receivables and payables of both entities, the difference, and per link or unlinked document the reason they differ. Timing reasons are explained and the counterpart's to resolve; mirror_rejected, unlinked_document and amount_differs are unexplained and fail the close check ic_reconciled. |
as_of, relationship_id (optional), entity_code (optional) |
GET /v1/ic/reconciliation |
list_intercompany_loans |
The loans between entities of the organization, oldest first: terms (amount, rate and its arm's-length basis, day count, dates, net investment), who requested and approved them, and what each stands at: principal outstanding, the day interest is accrued through and the interest accrued and not settled. Optionally one entity's (lender or borrower) or one state. |
entity_code (optional), status (optional) |
GET /v1/ic/loans |
list_intercompany_movements |
Drawdowns, repayments, interest accruals, settlements and declared group dividends by value date, each with both entities' entries and their state. Optionally one loan (id), entity, kind or value-date range (ISO dates). |
loan_id (optional), entity_code (optional), kind (optional), start (optional), end (optional), limit (optional) |
GET /v1/ic/movements |
list_consolidation_groups |
The organization's consolidation groups by code: the parent entity, reporting currency, framework (ifrs, fer, hgb) and whether its rules are verified so that a run is allowed, the latest approved version of every subsidiary (share, control basis, from when it is consolidated), the versions waiting for a second person and how many runs it has. group (code) gives only that group, with every member version in history. When the person asks about "the group" and there is more than one, ask which. |
group (optional) |
GET /v1/consolidation-groups
GET /v1/consolidation-groups/{group}/members |
list_consolidation_runs |
A group's runs (group code), newest date and version first: id, group date, status and how many blocking exceptions and warnings each has. Use the id with consolidation_run. |
group, limit (optional) |
GET /v1/consolidation-groups/{group}/runs |
run_consolidation |
Make a draft consolidation run of a group (code) at a month end (as_of, ISO date): each entity's posted ledger up to that day, the subsidiaries translated at the ECB closing, average and historical rates (IAS 21), intragroup balances, loans, income and expense and dividends eliminated, investment against equity with goodwill and non-controlling interests. It posts nothing to any entity's books and never changes an earlier run; it is a snapshot to read and check. Before running, check group_close_checklist (are the member periods closed, do the intercompany sides agree?) and tell the person what is still open; a run before then is a preview and says so in its exceptions. Then read consolidation_run with part exceptions first: a blocking exception (rate_missing, ic_difference above tolerance, unmapped_report_line, cta_unreconciled) means the figures are not complete, so say so before showing them. |
group, as_of, idempotency_key, comment (optional) |
POST /v1/consolidation-groups/{group}/runs |
consolidation_run |
A consolidation run (id from list_consolidation_runs), read from its snapshot. No part: the header (group date, framework, entities and member versions used, whether it is complete). part: balance_sheet (group balance sheet by report line, balanced), profit_and_loss (the group year, each month at its average rate), cash_flow (indirect method, with the effect of exchange rates), exceptions (blocking first: what the run could not do), eliminations (per rule E1 to E7 and pair of entities: what each side held, whether they agree, the lines that reverse them, residuals), rates (every rate used with its ECB fixing and dataset version) or translation_reserve (the reserve per subsidiary as balancing amount and as roll-forward, reconciled). Amounts are in the group's reporting currency; say which run and date the figures are from. |
run_id, part (optional) |
GET /v1/consolidation-runs/{consolidation_run}
GET /v1/consolidation-runs/{consolidation_run}/balance-sheet
GET /v1/consolidation-runs/{consolidation_run}/profit-and-loss
GET /v1/consolidation-runs/{consolidation_run}/cash-flow
GET /v1/consolidation-runs/{consolidation_run}/exceptions
GET /v1/consolidation-runs/{consolidation_run}/eliminations
GET /v1/consolidation-runs/{consolidation_run}/rates
GET /v1/consolidation-runs/{consolidation_run}/cta |
consolidation_trial_balance |
One entity's translated trial balance in a run, by account: the amount in its functional currency, the rate and the amount in the reporting currency (assets and liabilities at the closing rate, income and expense at each month's average, equity at the historical rate, the translation reserve balancing). The entities of a run are in consolidation_run (no part). |
run_id, entity_code |
GET /v1/consolidation-runs/{consolidation_run}/trial-balance |
group_close_checklist |
The group close checklist at a month end (as_of, ISO date) for a group (code): whether the member periods are closed, every intercompany relationship between members agrees, and, from the latest run at the date, every rate is available, every account maps, every elimination agrees within tolerance, the translation reserve ties and the balance sheet balances (pass, warn, fail, n/a; ready when nothing fails). A run older than the books is a warning: offer a new run. Closing a member's period is that company's person's act (request_period_close gives the link). |
group, as_of |
GET /v1/consolidation-groups/{group}/checklist |
list_room_types |
The hotel's room types, by entity and code: rooms, guests a room sleeps, the list price of a night today, rooms free tonight and the seasons with their nightly prices. Optional entity_code and room_type (one product code; needs entity_code). |
entity_code (optional), room_type (optional) |
GET /v1/room-types
GET /v1/room-types/{product_id} |
create_room_type |
Let rooms by the night: room_type: {entity, name (Double room), rooms (how many), nightly_price (net list price of one night), code?, max_guests? (default 2), currency?, valid_from?, rate_type? (default the VAT area's accommodation rate)}. Makes the product and keeps its rooms as capacity, so no night is let twice. Nothing is posted. |
room_type, idempotency_key |
POST /v1/room-types |
update_room_type |
Set a room type's rooms (rooms_count; refused below what is booked on a night from today on) or the guests a room sleeps (max_guests). |
entity_code, room_type, rooms_count (optional), max_guests (optional) |
PATCH /v1/room-types/{product_id} |
add_room_rate |
Add a season to a room type (by product code): season: {name (Winter season), first_night, last_night (YYYY-MM-DD, included), nightly_price, currency? (default the company's)}. Refused where it overlaps a season in that currency. Reserved stays keep their prices. |
entity_code, room_type, season |
POST /v1/room-types/{product_id}/rates |
remove_room_rate |
Remove a season by its id (list_room_types lists them). Reserved stays keep their prices. |
rate_id |
DELETE /v1/room-rates/{rate_id} |
quote_stay |
What a stay would cost and whether it is free, night by night: each night's price of one room (the customer's price, a season or the list price) and the rooms free, the total and available. arrival and departure YYYY-MM-DD; rooms_count default 1; customer (code) for its currency and prices. Nothing is booked. |
entity_code, room_type, arrival, departure, rooms_count (optional), customer (optional) |
GET /v1/room-types/{product_id}/quote |
list_stays |
Stays by arrival and number with room type, customer, guest, nights and prices, status and invoice. Optional entity_code; number (ST-..., needs entity_code); status (reserved, checked_in (in house), checked_out, cancelled); first_day and last_day (YYYY-MM-DD: those that leave on or after the first and arrive on or before the last; today for both lists who is in house or due today); limit. |
entity_code (optional), number (optional), status (optional), first_day (optional), last_day (optional), limit (optional) |
GET /v1/hotel-stays
GET /v1/hotel-stays/{stay_id} |
reserve_stay |
Reserve rooms for a customer: stay: {entity, room_type (product code), customer (code: who pays), arrival, departure (YYYY-MM-DD, the day they leave), rooms? (default 1), guests? (default one a room), guest_name?, reference? (the customer's order number)}. The rooms are booked for each night and the prices agreed now (quote_stay shows them first); refused when a night has too few rooms free. Nothing is posted. |
stay, idempotency_key |
POST /v1/hotel-stays |
cancel_stay |
Cancel a reserved stay (by number, ST-...; a no-show too), which frees its rooms. |
entity_code, number |
POST /v1/hotel-stays/{stay_id}/cancel |
check_in_stay |
Check the guests of a stay (by number) in, from its arrival day; room: the room numbers given (204, 205). |
entity_code, number, room (optional) |
POST /v1/hotel-stays/{stay_id}/check-in |
check_out_stay |
Check the guests of a stay (by number) out and draft its sales invoice: the nights at the agreed prices and extras [{product (code), quantity?, unit_price?, description?}] such as breakfast. departure (YYYY-MM-DD) when it is not the reserved day: an earlier day frees the nights left, a later one books the extra nights if free. Ask the person what the guests had before checking out; the draft is theirs to issue. |
entity_code, number, departure (optional), extras (optional) |
POST /v1/hotel-stays/{stay_id}/check-out |
invoice_stay |
Draft again the invoice of a checked-out stay (by number) whose invoice was rejected. |
entity_code, number |
POST /v1/hotel-stays/{stay_id}/invoice |
cash_forecast |
The company's cash for the next 13 weeks (from this week's Monday, amounts in its currency): opening (cash today), each week's inflow, outflow and closing cash, and lowest (the least cash at a week's end, below_zero when it goes negative). Built from open invoices and bills at the day each customer usually pays (basis, habit_days: days late on average over 12 months), payments not posted yet, the invoices recurring invoices and subscriptions will make, and recurring journals on a cash account; later is what falls after week 13. changes says what changed since the forecast kept in an earlier week (since): lines settled (paid or collected), new, moved to another week, with another amount, or that came_into_view; totals by kind and the opening cash then and now explain the move of the lowest point. Use it to explain the forecast: name the documents and parties behind a change. The largest lines are listed (all_lines for every one). as_of (YYYY-MM-DD) makes it as on another day. |
entity_code, as_of (optional), all_lines (optional) |
GET /v1/entities/{entity}/cash-forecast |
rolling_forecast |
The company's rolling forecast of its profit and loss, as the system last rolled it (amounts in its currency): each period's revenue, expenses and net (actual for closed periods, as posted; open ones from the average of the last three closed periods, never below what recurring invoices, subscriptions, recurring journals and depreciation already bring: scheduled), and ahead, the totals of the periods not closed yet. The system makes it and rolls it after each close; status is draft until a person approves the version. For the account lines and the comparison with what was posted use get_plan_version and plan_comparison with plan_id and version_id. |
entity_code |
GET /v1/entities/{entity}/rolling-forecast |
list_expenses |
Expenses, newest first: who paid, the merchant, day, total and VAT, the category and project, the card, what the AI reviewer checked, the bill and whether it is paid back. Optional entity_code, number (EX-..., needs entity_code), mine (only the person's own), status (draft, held, approved, posted, rejected, withdrawn), limit. |
entity_code (optional), number (optional), mine (optional), status (optional), limit (optional) |
GET /v1/expenses
GET /v1/expenses/{expense_id} |
expense_policy |
The company's expense policy: the limit per receipt and per expense account, the oldest receipt taken and the amount above which a project is named; what the AI reviewer holds an expense for. |
entity_code |
GET /v1/entities/{entity}/expense-policy |
claim_expense_without_receipt |
The person's draft expense without a receipt file: expense: {card_line? (a company card payment, from list_expense_card_lines), entity?, merchant?, receipt_date? (YYYY-MM-DD), currency?, total? (needed without card_line), description? (what it was for, why no receipt)}. The category and project fill in by themselves; without a receipt the AI reviewer holds it for a person. Submit it with submit_expense. |
expense, idempotency_key |
POST /v1/expenses |
update_expense |
Correct the person's draft before it is submitted: changes: {merchant?, merchant_country?, receipt_date?, currency?, total?, vat_lines? [{rate, net, vat}], account? (an expense account code), dimensions? ({"project": "P-LYON"}), description?, paid_with? (own or card), card?}. What is changed is marked as the person's. |
entity_code, number, changes |
PATCH /v1/expenses/{expense_id} |
submit_expense |
Submit the person's draft: the AI reviewer checks it against the expense policy; every check passes and it is booked at once and paid back in the next payment run (posted), one warns and it waits for a person in Approvals (held, with the checks). |
entity_code, number |
POST /v1/expenses/{expense_id}/submit |
list_expense_card_lines |
Company card payments as the issuers listed them, newest first, with the expense each is matched to. By default only those still waiting for their receipt (without_receipt); mine: only the person's own cards. |
entity_code (optional), without_receipt (optional), mine (optional), limit (optional) |
GET /v1/expense-card-lines |