7 Security Controls to Check Before Automating Invoice Processing

October 19, 2026 By Johan Curtis No Comments 11 minutes

What Automation Takes Away

Invoice fraud has always run on speed, and automation is about to hand it more speed than it has ever had. For decades the best defense in accounts payable was a slow desk, where a supplier’s request to change bank details sat for a few days until someone thought to pick up the phone. That pause probably caught more fraud than anyone ever measured. 

Software removes those days on purpose. Before any finance team lets a machine read, match and pay its invoices, seven security controls need checking. They belong in order of what their absence would cost, which is roughly the reverse of how most rollout plans list them, with reporting dashboards first and checks on bank details somewhere near the end.

Bank Detail Changes Deserve a Phone Call

The first control, and arguably the one that matters more than the other six put together, is an independent check on every change to a supplier’s bank details. Business email compromise drew 24,768 complaints and just over $3 billion in reported losses in 2025. Its classic form needs no hacking skill at all, only a convincing email asking that future payments go to a new account.

Speed matters here in a very literal way. When a fraudulent transfer is reported within hours, the receiving bank can often freeze the money before it moves on, a chance that tends to fade after a few days. Last year the FBI’s rapid-response team managed to freeze about 58 cents of every dollar it chased. Automation eats into those hours twice. For a start, the payment goes out sooner than it used to. Worse, the clerk who once might have frowned at that email never opens it.

The control itself is old and dull. A FinCEN advisory to banks described this exact scenario a decade ago, in which a criminal poses as a supplier to redirect invoice payments, and urged checking emailed payment instructions through more than one channel. In practice, any change to payment details triggers a call to a number already on file, placed by someone who didn’t receive the request, and nothing gets paid until that call is logged.

Patient fraudsters have learned where that control is weakest. The better-organized ones often change a supplier’s contact number weeks before they touch the bank account, so the callback, when it finally comes, rings their own phone. A new phone number deserves exactly the suspicion a new account number gets.

Where the Number on File Comes From

Every callback depends, in the end, on the moment a supplier’s details first entered the system, a step most onboarding checklists treat as clerical. Contact numbers still arrive on paper surprisingly often, from cards swapped at trade fairs and photographed on somebody’s phone, and one misread digit sends the verification call to a stranger. Paper still wins at trade fairs.

Where a card gets read matters as much as how well it’s read. Apryse treats the location question as a security matter when it compares ways of deploying an OCR engine. On-premises processing comes out as the most secure option, ahead of cloud and hybrid setups, because the scanned images and the text lifted from them stay on servers the company runs itself. For business card OCR technology that reasoning applies with extra force, since a card carries a named person’s direct line.

A new supplier’s phone number is worth checking against something the supplier published on its own, such as its website or a signed contract, before it becomes the number every future callback dials. After that, a request to change contact details can go through the same callback as a bank change, made to the old number. Holding the first payment to any new account for a few days costs little. If the real supplier then calls to chase a missing payment, which is how a good number of these schemes come to light, the money hasn’t left yet.

No Single Account Should Hold Every Permission

Second comes separation of duties, applied to the software’s own account. Finance departments learned long ago that whoever adds a supplier shouldn’t approve that supplier’s invoices. Plenty of automation projects go on to hand one system account the power to do both, and often to release the payment as well. More than half of the 2,402 cases in the largest global study of occupational fraud involved controls that were missing or had been overridden. An account holding every permission can behave like an override built into the design.

Splitting that account costs very little. Reading and matching can sit with one identity, payment proposals with another. Payment release then waits for a person, or for a second system whose credentials nobody else holds. Ask a vendor for the permission list on its integration account. It often comes with an apology attached. Over time, human accounts collect permissions the same way. A finance manager who raises her own approval limit for a quarter-end rush and forgets to lower it has done a fraudster’s setup work for free.

That fraud study also found losses caused by owners and executives running more than nine times higher than those caused by employees, which is worth remembering when deciding who may edit approval limits. Two people and a written record should sit behind any change to those limits. Temporary raises are the ones that linger, so the expiry date belongs on the request itself, filled in the day the raise is granted.

A four-person finance team can’t divide work this neatly, a problem federal internal control standards openly acknowledge. Their workaround for smaller organizations is more layers of review plus spot checks on transactions picked at random.

The Mailbox Nobody Locked

The third control guards the front door. Many teams automate invoice capture by pointing the software at a shared mailbox that has accepted mail from anyone for years, so a forged invoice now needs to fool a program rather than a person. Lookalike sender addresses, a staple of whaling attacks on finance staff, tend to fool that program more easily than a tired clerk, because nobody told the program to care who sent the PDF.

A dedicated invoice address that turns away mail failing sender checks takes care of much of this. Those checks cost little or nothing, yet among Inc. 5000 companies with a published email authentication policy, more than half still sat at monitoring only in 2026, logging forgeries instead of refusing them. Where an invoice comes from a domain the supplier record doesn’t list, it should land in front of a human.

Before launch, a month spent logging every incoming invoice is usually humbling. Personal webmail addresses turn up, and so does the supplier who still faxes. Every route on that list has to be shut, or given a rule of its own, before the software starts reading.

Supplier portals fix most of this in one go. Suppliers resent them, with some justice, because every customer seems to want a separate portal and a separate password.

Choosing What a Human Still Reviews

Fourth is the rule that decides which invoices a person ever sees. A first invoice from a new supplier should stop for review, and so should anything paying an account that changed recently. Amounts far outside a supplier’s history belong in the same pile, as does the urgent request sent just before a long weekend, when the people likely to question it have gone home. About three in four US organizations were affected by business email compromise in 2025, yet just 17 percent used AI against payments fraud, a sign that the paying is being automated faster than the checking.

Review has a way of decaying, though. Once a queue holds forty invoices a day and thirty-nine of them turn out fine, the reviewer stops reading and starts clicking. The timestamps give it away. You’ll see approvals landing four or five seconds apart for an entire afternoon.

The version of this control that works sends people fewer invoices, each with one specific question attached, such as whether the account number matches the one confirmed by phone in March. Planted errors help keep those few reviews honest. In a 2006 human factors study of operators using an automated aid, people often took the aid’s advice without checking it. Letting them watch it fail during training made them more careful, though not completely. Finance teams can copy that cheaply, because a known-bad test invoice slipped into the queue every few weeks shows whether anyone is still reading.

Duplicates That Exact Matching Misses

Duplicate detection comes fifth. Vendors love demonstrating it, probably more than it deserves, since catching the same invoice number twice is the easy part. The duplicates that cost money arrive with a letter added to the reference, or once by email and again through the portal. The sums involved are real. Over the twelve months to June 2026, data analytics run by New York’s state comptroller stopped or clawed back more than $6.8 million in duplicate payments.

Anyone resubmitting a paid invoice on purpose knows exactly which variations the software misses. Last year’s paid invoices make a useful test batch before launch, because the system’s own count of what it would have paid twice is hard to argue with. Many of the near-misses disappear once invoice numbers are compared with punctuation and leading zeros stripped out.

A Login That Can Move Money

Sixth, the automation platform needs the protection a bank login gets, since it can move money just as directly. A password alone shouldn’t open it for anyone, which means two-factor authentication on every account, including the finance director’s. The kind matters more than most rollouts admit. 

Text-message codes rank as a last resort in federal guidance on phishing-resistant MFA, which urges administrators and other high-value targets toward security keys or similar methods that a fake login page can’t capture. The people who can change approval rules or supplier records are exactly those targets. 

For everyone else, app prompts with number matching are a reasonable middle ground.

Connection Keys and Leftover Access

The harder problem sits in the connection keys that let the platform talk to the bank and the accounting system. Those keys can’t type in a code and rarely expire unless someone sets them to. They also leak. When researchers rechecked leaked secrets that had been confirmed as valid back in 2022, 64 percent were still active four years later. Internal code repositories, the ones companies tend to assume are safe, turned out six times more likely than public ones to hold hardcoded secrets.

Every key should have a named owner and a replacement date. Searching old chat threads and support tickets for pasted keys is worth an afternoon, since that’s where the unlisted ones often turn up. Then there’s the implementation partner, whose administrator login often outlives the project by months because nobody was ever given the job of switching it off. An audit trail belongs here too, stored where the platform’s own administrators can’t edit it, since a log the attacker can rewrite records nothing worth reading.

Ten Years of Supplier Banking Data

The archive comes seventh, and it sits last only because its damage arrives slowly. Every invoice the system reads is kept, with a supplier’s bank details and tax identifiers on it and often the name of the person who approves payments at that supplier. For whoever plans the next attempt, the archive is a ready-made shopping list. Plenty of cloud storage encrypts files while the provider keeps the keys. An archive using end-to-end encryption keeps even the provider from reading ten years of supplier banking data on a bad day.

Retention deserves the same scrutiny. Under IRS record-keeping rules, the usual period runs three to seven years, depending on the situation. Nothing in them requires old invoices to sit behind the same logins as this week’s payment run. Moving closed years to a separate store with its own access list, then deleting them when the period runs out, shrinks what a single stolen password can reach.

Approvals now get tapped through on phones in hotel lobbies, over networks nobody at the company chose, and that deserves a column of its own.

Who Is Left to Notice

One modest step is worth taking before anyone signs. Hand the vendor a week of the company’s own invoices and ask to see them run through these seven controls, in this order, with a name from the finance team next to every alert. If the answer for any control is “the system handles it,” that control deserves a second meeting.

Each control here ends with a person. Somebody has to place the callback to a number they trust, and somebody has to look at an exception as though it might be real. In many projects the business case for automating accounts payable rests largely on the cost of those people, and the finance director who signs off will reasonably be asked how many hours it saves.

Nobody in that meeting is likely to ask which of those hours were the ones in which someone used to notice.