Accounting and treasury
The engine reads your accounting and treasury systems into a knowledge base, for finance and treasury agents, using your own app or API client.
Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The ledgers are not transmitted, and LightHouse does not open the credential.
Read-only, always
Section titled “Read-only, always”These connectors only read, and read and write is refused: connect them as Read. Where the provider states a credential’s permissions, one that can write is refused, named. Where it does not, you confirm it only reads.
Connect in LightHouse
Section titled “Connect in LightHouse”You need the Client administrator (client_admin) role, signed in as a person, and a deployment whose engine reads this connector (compatibility reference) and keeps credentials in your own store.
- Make the app or API client at the provider, as the section below describes.
- Go to Setup and admin → Connectors, find the provider (search for it, or filter by family), and choose Connect.
- Name the fields listed, and leave the access level at Read.
- Paste the credential. Your browser seals it to your deployment; LightHouse never sees it.
- Your deployment keeps it and checks it. The card shows the result.
What the health codes mean
Section titled “What the health codes mean”| Code | The card says | What to do |
|---|---|---|
write_capable |
The key can withdraw, transfer, sign or trade: refused, nothing is read | Make a view-only key at the provider, pin it to your deployment’s egress addresses, and connect it again |
unverified |
The provider does not state the key’s permissions and it was not confirmed view-only | Check that it only reads, then connect it again with View-only confirmed set to yes |
scope_missing |
A granted scope writes, or a needed one is missing (Xero names it) | Make the app with the read scopes listed, and connect it again |
auth_failed |
The provider refused it | It may have expired or been revoked. Make a new one and connect it again |
- Reads: organisations, chart of accounts, contacts, invoices and bills, bank transactions, payments, manual journals, and the profit and loss, balance sheet and aged receivables and payables reports.
- Make: your own Xero app with read scopes only:
accounting.settings.read,accounting.contacts.read,accounting.invoices.read,accounting.payments.read,accounting.banktransactions.read,accounting.manualjournals.read,accounting.reports.profitandloss.read,accounting.reports.balancesheet.readandaccounting.reports.aged.read. Either consent it, or make it a custom connection. - Paste: the app’s client ID and client secret, and, for an app you consented to, its refresh token on a third line. The refresh token is rotated and written back to your own store at once.
- A scope that writes is named by the check, and nothing is ever written.
QuickBooks Online
Section titled “QuickBooks Online”- Reads: company, accounts, customers, vendors, invoices, bills, payments, journal entries and reports.
- Make: your own Intuit app and its consent. Intuit’s accounting scope (
com.intuit.quickbooks.accounting) is not split into read and write; this connector only reads, and nothing is ever written. - Paste: three lines: the client ID, the client secret, then the consent’s refresh token. Intuit rotates it; your deployment writes the new one back to your own store.
- Name: Company ID (the realm ID, digits) and Environment (production or an Intuit sandbox company).
Kyriba
Section titled “Kyriba”- Reads: bank accounts, balances, cash positions and forecasts, cash flows, payment status and third parties.
- Make: an API client by client credentials, with read permissions only: no payment initiation, transfer or approval.
- Paste: two lines: the API client’s ID, then its secret.
- Name: Kyriba sign-in address, Kyriba API address and View-only confirmed. Kyriba does not state an API client’s permissions, so you confirm it.
Where the credential is held
Section titled “Where the credential is held”LightHouse never opens these credentials. They are sealed in your browser, or by lighthouse-ai connect <provider> --credential-stdin, to your deployment’s own key, and your deployment keeps them in your own secrets store. LightHouse keeps the connection’s fingerprint, the access level, when it was checked and the check’s code: never the credential, and never what it reads. See Where every credential is held.
Removing it
Section titled “Removing it”On the card, choose Disconnect. Your deployment deletes the credential from your store. Revoke the app or client at the provider too. Documents already written stay in the corpus until you delete them.