The IT manager’s checklist for low-disruption finance automation deployment

Finance found the software. The business case is written, the demo went well, and the CFO is broadly in favour. Then the project lands on the IT manager’s desk with two question attached.

Fair questions! They’re usually the ones that decides the project. In most organisations the IT manager isn’t the budget holder for a cash management platform, but their “yes” is still required. A “no” sends finance back to look at other vendors.

The concern behind that “yes” is rarely the software itself. It’s the pattern IT managers have seen before: a new system that needs a database specialist, a network change, an ERP consultant and someone from IT sitting in every workshop for three months. Finance automation doesn’t have to work that way, but avoiding it means asking the right questions before the kickoff call, not after.

Here’s the checklist.

1. Get the IT resource plan in hours, by role, by phase. Not “minimal IT involvement” – an actual figure. How many hours from the ERP team, the network team, the database administrator, and at which points in the project. A vendor who has done this many times can answer precisely. One who can’t is telling you something.

Ask specifically whether the deployment needs specialists from more than one discipline at the same time. A project that needs your ERP person, your DBA and your network engineer in the same room for a week is a very different proposition from one that needs a few hours of ERP access and a firewall rule.

2. Understand exactly how it talks to your ERP. Cash management software has to read open items and write postings back. The mechanism matters: is it an API, a database connection, a file exchange, a middleware layer? Who maintains that connection when the ERP gets patched? Does the integration survive an upgrade? Or does it need rebuilding?

Cashbook integrates with Infor BPCS / LX, M3, MAPICS / XA, Oracle, Microsoft Dynamics 365, Sun Systems and TIMS, and the integration approach differs by system. Get the specifics for yours in writing before the project starts, not discovered during testing.

3. Find out who owns bank connectivity and file formats. This is the part IT usually inherits by accident. Bank statement files, remittance formats, lockbox feeds and outgoing payment files all have to arrive in a usable shape, and formats vary by bank and by country. For Essentra’s implementation, for example, Cashbook built support for the ClieOp03 format for Dutch domestic payments and then SEPA. It also embedded a vendor reference field in the outgoing payment file so the system could match each payment automatically on the incoming statement.

That’s specialist work. The question is whether the vendor does it or whether it quietly becomes an IT project. Ask who builds each format, who tests it with the bank, and who fixes it when a bank changes its layout in eighteen months.

4. Check the project against your ERP roadmap. If an ERP upgrade, migration or rollout is already in flight, say so early and ask how the deployment phases around it. Essentra were mid-BPCS rollout when they implemented Cashbook, so the project team designed and tested the automated bank statement upload and electronic payments solution in the Netherlands and Poland first, then rolled it out in stages. That’s the shape of a project that respects an existing roadmap instead of colliding with it.

5. Plan for security, access and data handling before the build. Where does the data sit? What leaves your network? What ports or firewall changes are required? How does the platform handle GDPR and PCI obligations? Cloud deployment removes most of the infrastructure burden. It doesn’t remove the requirement for review.

Segregation of duties deserves its own conversation. At Shaklee Malaysia, the implementation included unique security groups built to run alongside the company’s existing segregation of duties policy. Ask whether your team can configure user roles to match the controls your auditors already expect, so you don’t have to raise an exception.

6. Phase it: one entity, one bank, one process. The lowest-disruption deployments start narrow and widen once the pattern works. Portwest ran 19 bank accounts across 5 divisions with no standard format between countries or banks; the value came from standardising that, but the sequence matters. Prove the process on one account, then replicate to others.

7. Define parallel running and the rollback criteria. Agree upfront how long the old process runs alongside the new one. What evidence do you need to see before you shut down the old system? What’s your fallback if something fails in week one? Legacy manual processes produce enough errors to trigger their own rollbacks and restores. IT usually knows exactly what a bad week looks like. Write down the trigger conditions while everyone is calm, and plan for the issues you’re likely to hit.

8. Agree the automation rate that counts as “done”. Vague success criteria are how projects drift. Pick numbers and measure them. Real benchmarks from Cashbook implementations give you something to anchor on: Welders Supply & Gases reached over 90% auto-matching between the bank and their TIMS ERP, plus over 75% auto-matching of GL transactions. Chadwick’s automatically matches around 17,000 transactions at a 75–80% automation rate. Formica runs cash application automation above 90% and bank reconciliation above 95% across dozens of European bank accounts.

9. Make sure finance can configure the system without raising a ticket. Teams skip this item more often than any other, and it’s the one most likely to cost IT time later. Before Franklin Sports moved to Cashbook, their previous vendor configured the cash application tool behind the scenes, and Franklin’s team couldn’t tailor it. Users had no option but to work with the set configuration, so every issue and every improvement request became a support ticket – and resolutions were slow to arrive.

Ask who can change a matching rule, add a customer remittance format or adjust a tolerance. If the answer is “IT” or “the vendor”, you’ve just acquired a permanent queue.

10. Define the support escalation path before go-live. Who does a finance user call at 9am on the last day of the month? What reaches IT, and what goes straight to the vendor? A named account contact who knows your configuration is worth more than a generic ticket portal, particularly during close.

11. Count the tickets the old process is already generating. Manual processing produces its own IT workload: broken macros, spreadsheet errors, failed postings, rollbacks and restores. Portwest were manually downloading statements, running them through macros to identify payers, then allocating in the ERP – roughly 30 hours of manual processing a day before automation. Work of that shape generates support calls. Netting the new platform’s support load against the tickets it removes usually improves the case for the project considerably.

A well-scoped finance automation deployment asks IT for integration access, a security review and a defined number of hours – then hands day-to-day ownership to the finance team that uses it. It doesn’t need a new specialist skill set on your team, and it shouldn’t leave you maintaining bank file formats on evenings and weekends.

The eleven questions above are really one question from different angles: after go-live, does this system depend on my team or not? Get a straight answer to each before the project starts and the deployment stops being a risk to manage.

If you’re evaluating cash management automation and want to see the integration and resourcing detail rather than the feature list, request a Cashbook demo. We’ll walk your IT and finance teams through what the deployment involves for your specific ERP and banks.

Dave Ewing is the Marketing Manager at Cashbook, bringing over 20 years of expertise in marketing and technology to the role. He focuses on sharing valuable insights into cash management, accounts receivable automation, bank reconciliation, and ERP-integrated financial processes. In addition to his marketing efforts, Dave plays a key role in product development, helping to create innovative solutions that empower finance teams to work more efficiently.