Connecting a new tool to your accounting system takes about ninety seconds and a consent screen most people do not read. The decision underneath it deserves more than ninety seconds, because your ledger holds customer names, payment details, payroll figures and every supplier you work with.
This is not an argument against connecting anything. It is the set of questions worth asking first, and the handful of answers that should make you stop.
Read what it is asking for
Most consent screens offer one bundled permission and no detail. The distinctions that matter are rarely surfaced:
- Read against write. A tool that only reads can be wrong without being destructive. A tool that writes can post entries, and posted entries become your records.
- Scope. Does it need the whole ledger, or one account? Many want everything because it is simpler to build, not because they need it.
- Payroll and people data. Often bundled in without being mentioned, and it is the most sensitive thing in there.
- Banking connections. Reading a feed is different from being able to move money. Treat anything touching payment initiation as a separate decision with a higher bar.
If the permission is all or nothing and the tool only needs part of it, that is worth a question rather than a shrug.
The questions to ask the vendor
These are reasonable to ask of anyone selling software that touches your records, and the quality of the answer tells you a great deal.
| Question | What a weak answer looks like |
|---|---|
| Is our data used to train your models? | Anything other than a clear yes or no |
| Who at your company can see our ledger? | "Only authorized personnel" with no detail |
| Where is the data stored, and for how long after we leave? | No stated retention period |
| Can it post entries, or only propose them? | Vagueness here is the biggest flag on the list |
| What happens to our connection if you are acquired? | Never been considered |
The training question matters more than it sounds. Your ledger is a list of your customers, what they pay and when. That is commercially sensitive whoever holds it.
Keep the audit trail intact
The practical risk is less dramatic than a breach and far more common: entries appear and nobody can say who or what made them.
Insist on three things, all of which good tools already support:
- Its own login. Never connect a tool using a person's credentials. When that person leaves, you will not know what to revoke, and every entry the tool made looks like theirs.
- Attribution on entries. You should be able to tell, months later, which entries were automated and which a person made deliberately.
- A way to reverse a batch. If it miscodes four hundred transactions, undoing that should not be four hundred manual corrections.
If you cannot tell who made an entry, you cannot review the work, and an unreviewable ledger is a problem long before anyone questions a number in it.
Start smaller than they suggest
A sensible sequence costs you nothing and surfaces most problems early.
- Connect read-only first, and leave it that way for a full close cycle.
- Compare what it proposed against what your own process produced. Look at the disagreements rather than the totals.
- Grant write access to one narrow area, not the whole ledger.
- Review that area deliberately for the next couple of cycles before widening it.
Vendors rarely propose this because it lengthens their onboarding. It is still the right order, and anyone confident in their product will not object to it.
What would make us say no
Three answers are worth treating as disqualifying rather than negotiable: no clear statement on whether your data trains their models, no way to connect without a named person's credentials, and write access that cannot be scoped or reversed.
Everything else is a trade-off you can reason about. Those three remove your ability to reason about it later, which is the part that costs you.