Accounting Ledger Sync

Read and write invoices, bills, customers, and payments in QuickBooks/Xero-class accounting systems through an org Integration row, keeping money movement staged for human sign-off.

When to use

• You need to pull current invoice, bill, customer, or payment records from the org's accounting system for reconciliation or reporting.
• A workflow needs a new invoice, bill, or customer record created in the ledger.
• An existing ledger record needs correction (status, amount, due date) or removal.
• A payment, refund, or journal entry is ready to be proposed but must not execute without a human approving it.

Tools

• http-get
• http-post
• http-request

Playbook

1. Confirm the org has an active Integration row for the target accounting host (e.g. QuickBooks Online, Xero) before doing anything else. If none exists, stop and use send-message to tell a human which service and scopes are needed.
2. To read data, call http-get against the provider's REST API, e.g. GET https://quickbooks.api.intuit.com/v3/company/{companyId}/query?query=SELECT * FROM Invoice. Auth is injected automatically by the Integration row for that host — never ask for, echo, or hardcode credentials.
3. To create a new record, call http-post, e.g. POST https://quickbooks.api.intuit.com/v3/company/{companyId}/invoice with the invoice payload (customer, line items, amounts).
4. To update or delete an existing record, use http-request with the appropriate method, e.g. PATCH https://quickbooks.api.intuit.com/v3/company/{companyId}/bill or the equivalent Xero endpoint for a status change.
5. Never call an endpoint that executes a payment, refund, or journal entry directly. Instead, draft the proposed action (amount, payee, account, reason) and stage it.
6. Use create-task to open a task titled "APPROVAL: — — " containing the full proposed details, and assign it to a human reviewer.
7. Wait for the approval task to be completed before taking any further action; if the human approves, execute the corresponding http-post or http-request call and record the resulting confirmation number.
8. If the human rejects or edits the proposal, update the ledger draft accordingly or close out the task with the outcome noted.
9. On any 401/403 response, or if a needed capability (e.g. multi-currency conversion, tax filing) isn't available through the current API, stop and use send-message to flag the gap to a human rather than guessing.

Failure modes

• Treating a draft or proposed transaction as final and calling a mutating endpoint without a completed approval task.
• Retrying a create or update call after a timeout without checking whether the original request already succeeded, causing duplicate invoices or bills.
• Proceeding after a 401/403 by guessing at credentials instead of stopping and escalating via send-message.
• Giving tax, accounting, or investment advice instead of only reporting what the ledger data shows.

Done when

• The requested read, draft, or update is reflected accurately, and any money-moving action has a completed human approval task before execution.
• All API calls used the correct tool for the operation (http-get for reads, http-post for creates, http-request for updates/deletes) with no credentials handled directly.
• Any missing capability or authentication failure was escalated to a human via send-message instead of silently failing or working around it.