Why US Mid-Market Finance Leaders Should Run a Technology Discovery Sprint Before Committing to a Custom AP Automation Platform

This article is part of our series on Custom Accounts Payable Automation Platform Development for US Mid-Market Finance Teams: Building an Invoice Capture, Three-Way Match And Payment Execution System

Introduction: List Everybody Who Can Change a Bank Account

Before any platform conversation, and before an AP automation discovery sprint can produce anything useful, answer one question on paper: who can change a vendor’s bank account details today, through which systems and channels, and what verification is required.

Count the paths. The accounting system directly. A request to AP by email. A vendor portal if one exists. A spreadsheet somebody maintains. A helpful person in procurement with access they were granted for something else.

Then check whether any of those paths requires calling the vendor on a number the organization obtained independently, and whether that call gets recorded anywhere.

Most mid-market organizations find more paths than they expected and verification on fewer of them than they assumed.

That answer is your exposure, it costs an afternoon, and it is worth having whatever you decide about software. Three more measurements follow and all use records you already have.

The sprint is the decision layer of the full custom software development guide to custom AP platform development, whose working surfaces are web application development for AP, approvers and vendors.

Three More Measurements

Run a duplicate payment analysis across the last two years. Not exact-match: look for close amounts to the same vendor within short windows, payments across duplicate vendor records, and invoice numbers differing only by formatting. Most organizations find recoveries, and the figure is both a business case and money.

Check receiving coverage. Take last quarter’s purchase orders and count how many have receipts recorded in the system. If the answer is low, three-way matching will generate exceptions rather than automation, and that is an operational project before it is a software one.

Map segregation of duties as it actually is. For each of the four critical capabilities, list who holds it. Then look for anybody holding two that should be separated.

In a small finance team somebody usually does, and knowing exactly who and where is the input to designing compensating controls rather than discovering the gap in a test.

All three use existing records and all three produce findings worth acting on immediately, whatever the AP automation discovery sprint concludes about software.

What the Sprint Should Establish

The Vendor Master Exposure

Every path by which banking data can change, what verification applies to each, and the condition of the master itself including duplicates, dormant records and missing documentation. The highest-value finding and the one that frequently justifies a first release on its own.

The Duplicate and Leakage Analysis

Duplicate payment recovery potential, tolerance leakage where variances were accepted, and missed early payment discounts. Produces a value case in money rather than in hours saved, which is what survives a budget conversation.

The Receiving and Match Readiness Assessment

Purchase order coverage, receipt recording rates and the share of spend that is non-purchase-order. Determines whether matching automation is achievable and what the real automation ceiling is, which vendors tend to state optimistically.

The Control and Obligation Position

Segregation as it actually is, information reporting readiness, use tax practice, screening practice and any escheatment history including whether stale items have been voided. Established with the tax advisors, counsel and internal audit together.

The System Inventory

The accounting system and its customization, bank relationships and their capabilities, and every adjacent system holding payee or spend data. Sizes integration and frequently decides build against buy.

The obligations a sprint must establish are set out in IRS Form 1099 and Taxpayer Identification Matching, Use Tax Accrual on Untaxed Invoices, SOX Segregation of Duties, OFAC Vendor Screening and Escheatment of Stale Payments.

What the Finance Leadership Receives

A vendor master exposure map with every banking change path and its verification state, plus the master’s condition.

A leakage analysis quantifying duplicate recovery potential, tolerance leakage and missed discounts, in money.

A match readiness assessment with purchase order coverage and receipt recording rates, and an honest automation ceiling.

A segregation map showing who holds which critical capability today and where conflicts exist.

An obligation position covering reporting, use tax, screening and escheatment, with anything urgent flagged, particularly any history of voiding stale items.

A system inventory with integration effort per connection and bank capability assessed.

A product evaluation tested on the control layer rather than the feature list, with the banking verification question asked of every vendor directly.

A defined first release, which for most organizations should be the vendor master control layer.

And a costed comparison of at least three paths, adopt a platform, adopt and build the control layer around it, and build fully, with vendor master cleanup shown as a workstream in all three. The budget a sprint protects is detailed in How Much Does a Custom AP Automation Platform Cost?

Reading the Recommendation

Adopt a platform when the system inventory shows a standard accounting installation and the products’ control layers hold up, which for most mid-market organizations is the answer.

Adopt and build the control layer when a product handles processing well and leaves banking verification thin, which is a real finding and a far narrower project than a platform.

Fix receiving before anything when coverage is low, since matching automation onto poor receiving produces exceptions and nobody is happy.

Clean the vendor master before anything regardless, since every path leads through it and the work is the same whichever software follows.

Build fully when the accounting system is bespoke, when payables sits inside a larger operational platform, or when the organization sells payables processing.

One consideration applies whichever path is chosen: if the exercise found unverified banking change paths or a history of voided stale items, both are live and deserve attention this month rather than at implementation.

A consultant who tells you to clean the vendor master and fix verification before buying anything has read the findings correctly.

What a Consultant Should Know About This Work

Four questions establish whether a consultant has implemented payables rather than described it.

Ask where the fraud comes from. A good answer goes to vendor banking changes and business email compromise within a sentence. Anyone describing invoice fraud or duplicate payment as the primary risk has the order wrong.

Ask about touchless rate. The right answer qualifies it immediately: good on matched invoices from established vendors, meaningless if achieved by removing verification. Anyone presenting it as the objective has sold the metric rather than the outcome.

Ask what the system does with a stale check. The answer is track and escheat, never void as cleanup. Anyone offering a void-and-clear convenience has not understood the liability.

And ask about receiving. A consultant who asks about receipt recording rates before promising a matching percentage understands that the automation ceiling is set by your operations rather than by their software.

Red Flags in the Conversation

A sprint offered free and contingent on winning the build. A fixed price before the accounting system customization is assessed. Vendor master cleanup absent from the plan. Bank timelines not mentioned. Touchless rate promised without receiving data. No product comparison in a mature market. No internal audit involvement.

And the ones that should end the conversation: automated banking updates from email or portal, vendor creation from an inbound invoice, matching described as approving payment, segregation implemented as permissions with an admin override, screening matches cleared automatically, and voiding stale checks offered as a reconciliation feature.

The strongest positive signal is a partner who asks who can change a bank account before discussing anything else.

Conclusion

List every path by which banking details can change and what verification applies, since that is your exposure and it costs an afternoon.

Run a duplicate analysis on more than exact match, because it usually pays for the exercise.

Check receiving coverage before believing any matching promise. And evaluate products on the control layer, since that is where they differ and almost nobody asks. Hold every partner to that AP automation discovery sprint standard, including the software companies in the United States who would like to build it.

If you are weighing a custom AP platform, mapping every way a vendor’s bank account can change today is the afternoon to spend before any vendor conversation.

FAQ