Money
Your accountant's own books
Invoices issued here reach Xero or Zoho Books, and the payments they recorded come back. Nothing else crosses.
Your accountant already has a tool and is not going to change it, and adopting this product does not mean firing them. So the invoices raised here reach the books they already keep, without either side being retyped.
One owner per object
A document raised here is owned here and pushed. A payment recorded there is owned there and pulled. Nothing is merged field by field, and neither side ever silently overwrites the other — the alternative is a sync that produces a third version of the truth.
What does not cross, and why that matters more
The chart of accounts, the tax rates, the bank feed, the ledger and the month-end close all stay where they are. Two systems each keeping their own books and trying to agree is not an integration, it is two sets of books.
A document raised in their books does not appear here
That is the honest limit of an owner-per-object rule. Pulling those in would make this a two-way document sync, which it deliberately is not.
Connecting
- 1
Authorise
One entity at a time. A set of books belongs to a company, and sending two entities into one is how a consolidated mess is made that nobody can unpick.
- 2
Choose which books
A Xero login can hold several organisations and a token is granted against all of them. Until this is answered nothing is filed — writing into whichever came back first is how a year of invoices lands in the wrong company's accounts.
- 3
Leave it alone
It sweeps hourly, both directions, and is safe to run twice.
Zoho keeps regional data centres
An account created in Europe cannot be reached at the American address, and the 401 that results says nothing about regions. The connect form asks where the account was made, and an unknown region is refused rather than quietly defaulted — which would make the wrong data centre permanent.
What goes out
- Only issued documents. A draft changes hourly, and filing one would fill the books with things that are not documents yet.
- They arrive already approved rather than as drafts to sign off twice.
- A sale is filed as money owed to you and a bill as money you owe. A credit note goes to its own place rather than as a negative invoice.
- The tax name is sent, never the rate. Both providers keep their own tax codes and your accountant has set them up already; a percentage would create a duplicate rate in their books or be rejected outright.
A document that fails to cross says so on the document
Which invoices did not file, and why, is a question with an answer. One failing never stops the rest — an accountant who cannot get last month's invoices across because one has a tax code their books do not know goes back to retyping all of them.
What comes back
Payments they recorded. An accountant marking an invoice paid in their own tool is the ordinary case — it is where the bank statement is being worked through — and an invoice showing as outstanding here because of it is what makes people stop trusting the debtors report.
A payment larger than what is outstanding is refused, not clamped
Elsewhere a settlement caps at the outstanding amount, because the person doing it is looking at the screen. Here nobody is: an amount larger than what is owed means the two sides disagree about the document, and quietly recording part of it hides that.
Who can do what
| Action | Needs |
|---|---|
| See the connections and what is waiting | finance:view |
| File now, read payments now | finance:edit |
| Connect a set of books, or disconnect | finance:configure |
Connecting grants this product permission to write documents into somebody else's ledger, which is why it sits with the higher authority. Disconnecting deletes the credential.