Most AR automation implementations fail not on the software but on the data readiness and process clarity before go-live. The questions to ask first.
When an AR automation implementation doesn't deliver — and a meaningful share of them don't, particularly in the first 90 days — the postmortem almost always points to the same category of causes: the ERP data wasn't clean enough for the system to ingest reliably, the AR team hadn't agreed on which customer segments should be automated vs. manually managed, the sales team wasn't informed about changes to the collections outreach cadence, or the integration required more IT involvement than anyone had scoped. The software worked fine. The conditions for the software to work were not in place.
This checklist exists because evaluating AR automation software is only half the evaluation. The other half is evaluating your organization's readiness to implement it. Both matter. Answering these 12 questions before you sign a contract won't guarantee a smooth implementation — but it will surface the blockers that predictably derail them.
Data Readiness (Questions 1-4)
1. Is your AR aging data complete and consistent in the ERP?
AR automation systems ingest aging data to build customer payment profiles and prioritize work queues. If your ERP has inconsistent customer records (duplicate customer IDs, inconsistent naming conventions, payments posted without invoice references), the automation system will inherit that data quality problem. Before implementation, run a data audit: how many open invoices have missing or incorrect customer references? How many payments in the last 12 months were posted to a "miscellaneous" or "unmatched" bucket? Any system that requires clean AR data should have a data quality pre-check as part of the implementation process. If yours doesn't, ask why.
2. Do you have at least 12 months of payment history per customer?
Predictive capabilities require historical payment data to train on. Twelve months is a reasonable floor; 18-24 months is better for capturing seasonal variation. If you've recently migrated ERPs or have a significant portion of your customer base with less than a year of payment history in your current system, the predictive layer will have limited accuracy for those accounts. Know this upfront and calibrate expectations accordingly.
3. Are your payment terms coded consistently in the ERP?
This gets repeated in multiple contexts because it's a persistent source of problems. If a customer's contract specifies net-30 but their ERP record shows net-45, every payment they make will be flagged as early or the dunning will fire at the wrong time. Audit the match between contracted terms and ERP-coded terms for your top 50 customers before any implementation. This audit is useful regardless of whether you're implementing automation.
4. Can you export a clean, date-attributed payment history from your ERP?
A basic test: can you produce a CSV of your last 18 months of invoice payments with columns for invoice number, invoice date, due date, payment date, customer ID, and amount? If this export requires significant manual cleanup before it's usable, the automation system's implementation will require the same cleanup — and it won't happen automatically. Run this export before vendor demos; it's a useful data quality diagnostic.
Process Clarity (Questions 5-8)
5. Do you have documented dunning sequences, or is your current process informal?
AR automation systems need to be configured with sequences — at what trigger, what message goes out, through what channel, to which contact. If your current dunning process is "whoever is available sends a reminder when they notice an invoice is late," you don't have a process to automate — you have a behavior that needs to be formalized first. The time to design your dunning sequences is before implementation, not during it.
6. Have you segmented your customers for different dunning treatment?
The default mode for most AR automation implementations is to apply a single dunning cadence to all accounts. This typically underperforms relative to segment-specific cadences, but it's the path of least resistance during implementation. Before go-live, decide: which customers should receive automated dunning vs. personal outreach? Which accounts are "hands off" during a sales negotiation or contract renewal? Which customers have explicit requests about communication channel (some AP departments refuse email, some prefer phone only)? These decisions can be revisited after go-live, but having a first-pass segmentation prevents the common implementation failure of automated dunning going to accounts where it shouldn't.
7. Has sales been informed and bought in?
Collections outreach affects customer relationships, which sales owns. If automated dunning emails start going to accounts the sales team is actively managing, and sales didn't know it was happening, you will have a conflict on your hands within the first two weeks. The fix is alignment before go-live: share the planned dunning sequences with sales leadership, identify the accounts that need "do not automate" flags, and establish a process for sales to flag new accounts that should be excluded from automated follow-up. This is a people and process step, not a software step — but it's as critical as any configuration decision.
8. Is there a defined owner for AR automation operations post-implementation?
AR automation systems require ongoing configuration — sequences get updated, new customer segments get defined, edge cases get handled. If no one has ownership of this post-go-live, the system will drift: sequences that were set up at implementation never get updated even as your customer base changes, overrides accumulate without review, and the AR team gradually stops trusting the automated queue and reverts to manual processes. Define who owns the system operationally before you sign. It doesn't have to be a full-time role — but it has to be someone's explicit responsibility.
Integration and Vendor Questions (Questions 9-12)
9. What ERP integration method does the vendor use, and what IT resources are required?
ERP integrations range from read-only API connections (low IT involvement, works with standard ERP configurations) to custom middleware builds (significant IT involvement, requires ongoing maintenance). For mid-market companies where IT resources are limited, the former is much more appropriate than the latter. Verify specifically whether the vendor has a live, maintained integration with your ERP version — not just "we support NetSuite" but "we have a current OAuth integration with NetSuite 2024.1 that other customers are using." Ask for a reference customer on your specific ERP version.
10. What is the vendor's customer support response time, and what does implementation support include?
AR automation affects live financial operations. If something breaks in the dunning sequence on a Tuesday morning, a 48-hour support response time is a meaningful business problem. Verify response time SLAs for your contract tier, and confirm what implementation support is included — dedicated onboarding? Implementation call hours? A support rep familiar with your configuration? This is especially important for smaller vendors where "implementation support" may mean one person across many simultaneous implementations.
11. What is the data handling and security posture?
AR data is financially sensitive. It contains customer payment history, invoice amounts, and payment terms — information that is confidential and, if mishandled, creates counterparty relationship risk. Verify: where is data stored, who has access, is data encrypted in transit and at rest, what is the vendor's breach notification policy, and does their security posture meet your company's vendor compliance requirements (particularly relevant if your company has SOC 2 requirements on its own vendors). For companies subject to specific data residency requirements, verify whether the vendor can accommodate them.
12. What does success look like in 90 days, and how does the vendor measure it?
Ask any AR automation vendor you're evaluating to define the specific metrics they expect to move for your company in the first 90 days, how they'll be tracked, and what happens if those metrics don't materialize. A vendor who answers this question confidently — with specific metrics tied to your AR profile, not a generic benchmark — is describing an implementation process with defined success criteria. A vendor who gives a vague answer is either not tracking outcomes or doesn't have enough evidence to make specific claims. Either is a yellow flag.
We're not saying these questions should kill a deal if the answers are imperfect. Some gaps — like incomplete payment history for recent customers — are knowable constraints that can be planned around. The point is to have the information before you commit, so that the implementation plan addresses real constraints rather than discovering them at go-live.
When James Okonkwo built the initial Cashvyne onboarding process, the explicit design goal was to answer questions 1-4 automatically as part of setup — running a data quality check on the ERP connection before any configuration begins, surfacing gaps in payment history, and flagging term coding inconsistencies before they affect the first dunning sequence. The reason is simple: those four data problems are the ones we see most often derail mid-market implementations, regardless of software. Fixing them before the system is live is an order of magnitude faster than diagnosing them after automated dunning has already produced unexpected results.