Almost every automation software evaluation has the same moment. Around slide three or four, a wall of logos appears: your ERP, your bank, your CRM, your email, your cloud storage, and two hundred more. The line that goes with it is usually some version of "it connects to everything."
It's a reasonable thing to ask about. If the tool can't read from and write to your systems, it's useless. But the answer to "does it connect?" only tells you that data can move. It tells you nothing about what happens when an invoice is 2% off the purchase order, when a vendor exists twice in the vendor master, or when a payment needs approval from someone who's on vacation.
And that, not the connector, is where finance automation projects are won or lost.
1. What a connector actually solves (and what it doesn't)
A connector does three things: it authenticates against a system, reads or writes records, and translates fields from one format to another. It's transport. Ten years ago that was hard and expensive; today it's largely a commodity. Plenty of platforms do it well.
What a connector doesn't solve is what the process means: which field is the source of truth, which tolerance applies to each spend category, what to do when the bank reference arrives truncated, who decides each ambiguous case, and what evidence the auditor will ask for. None of that ships in an integrations catalog.
2. Why breadth gets sold first
There's no bad faith in this; there's a structural reason. Breadth is easy to demo (a logo is a logo), easy to count (four hundred beats two hundred), and easy to compare in an RFP spreadsheet. Depth, on the other hand, can only be demonstrated with your data and your exceptions, and that doesn't fit into a 40-minute demo.
On top of that, a horizontal platform has to serve thousands of companies across very different industries. It makes sense for it to optimize for what they all share (transport) and leave the specifics to whoever implements it. That's a legitimate design choice. The point is that the depth work doesn't go away: it moves to your team or to an implementation partner. The useful question is whether you knew that's what you were buying.
"A connector tells you two systems can talk. It doesn't tell you whether they know what to say to each other."
3. Where the difference shows up: an accounts payable example
Take three-way matching: invoice, purchase order, and goods receipt. In the demo, a clean invoice arrives by email, gets read, gets matched to the PO in the ERP, and gets approved. It works. It connects to everything.
Now think about what actually shows up on a random Tuesday:
- An invoice with three lines against a two-line PO, because the vendor broke out freight separately.
- A partial receipt: 60% of the goods arrived and the invoice is for the full amount.
- A vendor set up twice under different IDs, something we cover in why duplicate payments are a data problem before they're an AI problem.
- An invoice in a foreign currency, with an exchange rate from a different date than the PO.
- A tolerance that should differ between materials and professional services.
Every tool on the market can read those invoices. The difference is whether someone identified these cases before the pilot and defined an explicit behavior for each one: process automatically, route to a person, or block. In practice, most of the design work in an automated finance process tends to live there, in the exceptions, not on the happy path.
4. Reframing the question
This isn't about no longer asking about integrations. It's about asking the questions that reveal depth first. A few concrete reframes:
| Breadth question | Depth question |
|---|---|
| "Does it connect to our ERP?" | "What does it do when the invoice and the PO in our ERP don't match?" |
| "Can it read PDFs?" | "What does it do with a crooked scan, or two invoices in the same file?" |
| "Does it have approval workflows?" | "Who sets the thresholds, who can change them, and where is that logged?" |
| "Is it no-code?" | "Who maintains the logic when the process changes, and with what documentation?" |
| "How long does implementation take?" | "How long until it handles our real data correctly, exceptions included?" |
One useful signal: notice whether the person presenting the solution asks about your exceptions before showing you the tool. Someone who understands a process deeply knows where it breaks and wants to know how yours breaks.
5. When breadth really is the right question
To be fair, there are scenarios where connector count is exactly what matters.
- Syncing structured data between modern systems. If you need CRM customers to show up in the ERP with the same fields, it's a transport problem, and a broad integration platform is the right tool. We go into this in RPA, iPaaS, or AI agents: what you're actually being sold.
- Many simple workflows instead of one critical one. Notifications, file copies, reminders: tasks with little logic and low risk.
- An internal team that can build the depth. If you have people who know the process and can model its rules, a broad platform can be a solid foundation.
Breadth isn't a flaw. It just isn't the first question when the process involves judgment, money, and an audit at the end.
A practical order for your next evaluation
- Pick one specific process. Not "automate finance," but "three-way matching for domestic vendor invoices." Ideally a representative one, not just the easiest, as we argue in what mid-market finance teams get wrong about starting small.
- Document its exceptions before you talk to vendors. The ten most frequent, with a real example of each. That document is worth more than any RFP.
- Bring those cases to the demo and ask them to process them. With your data, not the vendor's. If that isn't possible in a demo, make it a tightly scoped pilot.
- Only then, check connectors. Not "how many do you have?" but "do you reach the systems this process needs?"
- Evaluate how it's governed. Which decisions require approval, who can change the rules, and what evidence is kept. The five tests in the real difference between a dashboard and a control apply here.
The connector list tells you whether something is possible. Depth tells you whether it will work on close day, with the invoice nobody expected. If you'd like to pressure-test your process's exception list with someone who has worked through a few, reach out.