Rillet

Creates a credit memo. Opens a customer credit memo that reduces receivable exposure before you allocate it to specific invoices. Capture subsidiary, customer, line-level reasons, and tax treatment so finance can audit why the balance changed.

create_a_credit_memo

Creates a customer. Creates a new customer in the Accounts Receivable catalog. Required fields: name. When providing a billing or shipping address, line1, city, zip_code, and country are required. State is required for United States addresses (use a 2-letter code such as 'TN' or 'CA') and may be omitted where it does not apply.

create_a_customer

Creates a customer family. Creates a family from customers that do not already belong to one. A child may report to another child, so a multi-level hierarchy is created in one call.

create_a_customer_family

Creates a draft contract. Stages a contract in the \"draft\" holding state instead of creating it directly as an active contract. Draft contracts appear in the Rillet UI under \"Draft\" for a human to approve or reject. ## Deduplication **To prevent duplicate draft contracts on retry, supply at least one `external_references` entry with a stable `(type, id)` pair.** When you POST again with any matching `(type, id)` pair, the prior draft record is replaced with the new payload. Draft contracts created without any `external_references` are not deduplicated — every POST creates a new record. ## External reference types Each reference's `type` must match a slug already defined under Rillet Settings → External References for the organization; unknown slugs return a 400. References attached at create time are preserved when the draft contract is promoted to an active contract. ## Promotion Promotion to an active contract happens through the Rillet UI. The public API does not currently expose a programmatic promotion endpoint.

create_a_draft_contract

Creates a field. Defines a new custom field (text, number, pick list, etc.) that can be attached to supported Rillet entities for reporting and automation. After creation, use create-field-value to seed allowed pick-list entries or default values teams should see in the UI.

create_field

Creates a field value. Adds a selectable value to a pick-list style custom field so users and APIs can tag entities with consistent taxonomy. Values inherit the field’s scope, so create them after the parent field exists and before importing records that reference the new code.

create_field_value

Creates a journal entry. Posts a balanced manual journal entry with explicit debit and credit lines, posting date, and subsidiary scope for GL corrections. Prefer dedicated AR or AP APIs when the business event already exists; reserve this for adjustments your automation cannot model yet.

create_a_journal_entry

Creates a product. Creates a new product (good or service) that can be referenced on contracts and invoices. Choose pricing and revenue behavior consistent with how you bill customers (one-time, recurring, usage, etc.).

create_a_product

Creates a reimbursement payment. Records a cash payment that settles all or part of a reimbursement.

create_a_reimbursement_payment

Creates a vendor. Adds a vendor master record the accounts-payable team can select on bills, vendor credits, and payments. Capture legal name, remit-to address, default currency, and payment terms so downstream bills inherit correct due dates and banking instructions.

create_a_vendor

Creates a vendor credit. Records a new vendor credit memo amount that reduces future payables without yet touching specific bills. After creation, use apply-vendor-credit to allocate the balance across one or more open bills.

create_a_vendor_credit

Creates an account. Adds an account to the chart of accounts for the organization. The account currency is inherited from the organization, its status is ACTIVE, and its default grouping and closing behavior are derived from the selected type and subtype.

create_an_account

Creates an invoice. Rillet supports two invoice scope types: FULL and REVENUE_RECOGNITION_ONLY. The selected scope determines how the invoice is created and what information the user needs to provide. The FULL scope is used when the invoice is generated and sent directly from Rillet. In this case, Rillet automatically assigns the invoice number. The REVENUE_RECOGNITION_ONLY scope is intended for situations where the invoice is issued from another system and only needs to be recorded in Rillet for accounting purposes. In this workflow, users must provide the invoice number manually. Other fields can be populated based on the data imported from the external system. For example, if your organization issues invoices through an external billing platform but tracks financials in Rillet, you should select REVENUE_RECOGNITION_ONLY. If Rillet handles the entire invoicing and sending process, choose the FULL scope.

create_an_invoice

Creates an invoice payment. Records a manual cash receipt against an open invoice by amount, effective date, and a GL account code that maps to a funded cash account. Rillet resolves the account code to a cash account before posting, so verify chart-of-accounts mapping when automations fail validation.

create_an_invoice_payment

Deletes a bank account. Removes a bank account definition when the entity closed the account or you mistakenly created a duplicate connector mapping. Ensure no scheduled payments or open reconciliation batches still target this bank account before deletion.

delete_a_bank_account

Deletes a bank transaction. Removes a bank transaction row that was imported twice or created in error before it affects reconciled cash balances. Confirm treasury agrees the underlying bank activity will not return on the next feed pull before deleting.

delete_a_bank_transaction

Deletes a bill. Removes a bill that should no longer drive AP balances, typically while it remains in draft or was created in error. Verify no posted payments, accrual journals, or vendor credit applications still reference the bill before deleting.

delete_a_bill

Deletes a bill payment. Reverses a previously recorded bill payment when the disbursement failed or was duplicated, restoring the bill balance accordingly. Treat this as a corrective action with the same controls you apply to voiding treasury transactions in your close process.

delete_a_bill_payment

Deletes a charge. Drops a charge that should not influence spend reporting, for example duplicate imports from a card processor feed. Ensure finance agrees the underlying bank activity will not be re-imported before removing the charge permanently.

delete_a_charge

Deletes a contract. Permanently removes a contract when your business rules allow deletion. Confirm downstream invoices, revenue schedules, and integrations no longer depend on this contract before deleting it.

delete_a_contract

Deletes a credit memo. Removes a credit memo that should no longer affect AR balances, typically while it is still draft or unused. Confirm no invoice applications or downstream revenue adjustments depend on this memo before calling delete.

delete_a_credit_memo

Deletes a customer. Permanently deletes a customer. Verify no active contracts or open invoices reference this customer first.

delete_a_customer

Deletes a draft contract. Permanently removes a draft contract along with its line items and external references. Use this to programmatically reject a draft contract instead of doing it from the Rillet UI.

delete_a_draft_contract

Deletes a field value. Retires a pick-list option that should no longer be selectable while keeping older records intact for read-only history. Confirm no automation or validation rules still require the value before removal to avoid breaking bulk imports.

delete_field_value

Deletes a journal entry. Deletes a manual journal entry that should be excluded from the ledger, typically prior to period lock while corrections remain allowed. Verify dependent reconciliations or downstream consolidations no longer rely on the entry before removal.

delete_a_journal_entry

Deletes a product. Permanently removes a product. Ensure no in-flight contracts or invoices require this product before deleting.

delete_a_product

Deletes a reimbursement. Removes a reimbursement that was created prematurely or duplicated during intake so it no longer blocks payroll totals. Confirm no outbound payments or GL accruals were posted against the reimbursement before deleting it.

delete_a_reimbursement

Deletes a reimbursement payment. Reverses an uncleared reimbursement payment that was recorded in error.

delete_a_reimbursement_payment

Deletes a usage record. Removes the usage entry for a single contract item on a specific calendar date. This is narrower than upsert-a-usage-record and is ideal when you need to wipe a mistaken day without resending the entire usage payload.

delete_a_usage_record

Deletes a vendor. Removes a vendor you no longer expect to pay. Confirm no open bills, credits, or scheduled payments still reference this vendor to avoid orphaned payables.

delete_a_vendor

Deletes a vendor credit. Permanently removes a vendor credit that should not remain in the subledger. Ensure no applications or downstream reconciliations still rely on this credit before deleting.

delete_a_vendor_credit

Deletes an invoice. Permanently removes an invoice when your policy allows it (for example draft or voided states). Confirm no downstream payments or revenue postings still depend on this invoice.

delete_an_invoice

Deletes an invoice payment. Reverses a previously recorded uncleared invoice payment, restoring the invoice balance accordingly. Only uncleared payments can be deleted; cleared or reconciled payments are rejected. Treat this as a corrective action with the same controls you apply to voiding treasury transactions in your close process.

delete_an_invoice_payment

Ends an open-ended contract. Sets an explicit end date on a contract that previously had no close date (open-ended). Provide the final end_date in the request body; downstream invoicing and revenue recognition honor the new boundary.

end_an_open_ended_contract

Gets API key information. Confirms the caller’s API key is recognized and returns basic identity metadata such as organization context when authentication succeeds. Integrations should call this during bootstrap or rotation to distinguish invalid keys from broader connectivity failures.

get_api_key_information

Gets custom fields. Retrieves custom field definitions and their pick-list values for the organization. Use the returned field ids with create-field-value and update-field-value when enriching core entities.

get_fields

Gets payment method. Returns the payment method configured for auto-payment for the given customer.

get_payment_method

Lists all accounts. Returns the chart of accounts for the organization tied to the API credentials. Use optional filters (for example updated.gt) to sync only accounts changed since a prior run. Account ids are stable identifiers used when creating journal entries, bills, and other postings.

list_all_accounts

Lists all approval workflows. Returns every approval workflow in the organization tied to the API credentials, active and inactive, grouped by the kind of record they apply to and ordered by ascending `priority` within each group. This endpoint is not paginated and returns the complete set.

list_all_approval_workflows

Lists all bank accounts. Returns cash bank accounts configured for the organization, optionally filtered by subsidiary. Bank account ids anchor transaction import, reconciliation, and treasury automations.

list_all_bank_accounts