How Should Sage Intacct Users Protect Against Payment Fraud?

Sage Intacct payment fraud prevention starts with the ERP's built-in controls but can't end there. The native security features handle application-level risks well, but they don't cover the payment execution layer where most fraud actually lands. Sage Intacct provides role-based access, audit trails, segregation of duties, and SOC1/SOC2-certified infrastructure. Those controls protect your financial data inside the system. The problem is that payment fraud increasingly happens outside the system: vendor impersonation emails that trick your team into changing banking details, check interception, and invoice manipulation that passes every approval workflow because the invoice itself looks legitimate. According to AFP's 2025 Payments Fraud and Control Survey, 79% of organizations experienced attempted or actual payment fraud in 2024. That number has barely moved in years despite growing investment in ERP security. The reason is straightforward: ERP controls and payment fraud controls operate in different layers, and most organizations only have one of them covered.

Key Takeaways

• Sage Intacct's native security covers application access, audit trails, and compliance. It doesn't cover payment-level fraud like vendor impersonation, check interception, or banking detail spoofing.

• BEC caused $2.77 billion in U.S. losses in 2024, according to the FBI's Internet Crime Report, with the average incident costing roughly $129,000. These attacks exploit the vendor verification gap that ERPs can't close.

• Checks remain the most targeted payment method for fraud, according to AFP's 2025 Payments Fraud and Control Survey. Virtual cards eliminate this exposure entirely because each payment uses a single-use number.

• Payment platforms that layer onto Sage Intacct add validated vendor banking, automated anomaly detection, and managed verification that the ERP wasn't designed to provide.

What Payment Fraud Controls Does Sage Intacct Provide Natively?

Sage Intacct's security infrastructure is genuinely strong for what it's designed to do. The platform holds SOC1, SOC2, PCI, HIPAA, and ISO 27001 certifications, which means the application itself meets rigorous third-party security standards. The native controls protect your financial data and enforce who can do what inside the system. They don't, however, verify that the vendor you're paying is who they claim to be, or that the banking details attached to a payment instruction haven't been compromised.

How do Intacct's audit trails and access controls work?

Every user action in Sage Intacct generates an audit record: user ID, timestamp, IP address, and the specific data that was created, changed, or deleted. Role-based access controls let you restrict who can view, create, or modify records by module, entity, department, or custom dimension. You can enforce segregation of duties so the person entering invoices can't also approve payments. These are table-stakes controls for any modern ERP, and Intacct implements them well. The audit trail is particularly useful during external audits because it creates an immutable record of every financial transaction and configuration change. But audit trails are detective controls, not preventive ones. They help you reconstruct what happened after a fraud event. They don't stop the event from happening.

What does Sage Intacct's transaction security actually prevent?

Intacct's transaction security rules can restrict specific actions: preventing edits to posted transactions, blocking certain journal entry types, or requiring secondary approval for transactions above a threshold. These rules reduce internal fraud risk by limiting what users can do within the application. What they can't prevent is external fraud that enters the system through legitimate channels. When an AP clerk receives a convincing email from what appears to be a known vendor requesting a banking change, and the clerk updates the vendor record following your standard process, no transaction security rule fires. The payment goes to the fraudster's account through your approved workflow. The ERP did exactly what it was told to do.

Where Does Sage Intacct's Fraud Protection Fall Short?

The gap is between application security and payment security. Sage Intacct secures the application. Payment fraud targets the workflow outside the application.

Why is vendor banking verification the biggest gap?

Because it's where the money moves. An attacker who compromises a vendor's email account or impersonates a vendor with a look-alike domain can submit a banking change request that looks entirely legitimate. Your AP team follows the process, updates the record, and the next payment goes to the wrong account.

The FBI's 2024 Internet Crime Report documented $2.77 billion in BEC losses across 21,442 reported incidents in the U.S., putting the average loss per incident at roughly $129,000. These aren't sophisticated technical exploits. They're social engineering attacks that exploit the gap between "is this person authorized to make this request in our system?" and "is this person actually who they say they are?"

Sage Intacct can answer the first question. It can't answer the second.

How does check fraud bypass ERP controls entirely?

Checks are physical instruments that leave your control the moment they're mailed. A check contains your bank account number, routing number, payee name, and amount in plain text. Check washing, mail theft, and alteration don't interact with your ERP at all.

AFP's 2025 survey found that checks remain the payment method most frequently targeted by fraud, hitting 63% of responding organizations. Despite this, 91% of surveyed organizations still use checks, and more than 75% said they have no immediate plans to stop. That disconnect between fraud exposure and payment behavior creates a persistent vulnerability that no ERP control can address.

The only way to eliminate check fraud exposure is to stop issuing checks. Moving payments to electronic methods, especially virtual cards where each transaction uses a unique, single-use card number, removes the static account information that makes checks vulnerable.

What Are the Most Common Payment Fraud Attacks Targeting AP Teams?

Payment fraud targeting accounts payable falls into a few distinct categories, and understanding the mechanism behind each one helps you figure out which controls actually matter.

How does business email compromise target accounts payable?

BEC attacks targeting AP typically follow one of two patterns. In the first, the attacker compromises a real vendor's email account and sends a legitimate-looking request to change banking details. Because the email comes from the vendor's actual address, it passes basic verification. In the second, the attacker creates a domain that looks similar to a known vendor's domain and sends a convincing email requesting payment to a new account.

Both patterns exploit the same gap: your team has no automated way to verify that a banking change request is legitimate. The verification happens manually, often by calling a phone number provided in the same potentially compromised email. 63% of organizations reported experiencing BEC in 2024, according to AFP's 2025 Payments Fraud and Control Survey, and 71% of U.S. companies report an increase in AI-powered fraud attempts over the past 12 months, according to Trustpair's 2026 "Fraud in the Cyber Era" report. These attacks are getting harder to detect because the language and formatting are increasingly polished.

What makes vendor impersonation attacks so effective?

They work because they target process, not technology. The attacker doesn't need to breach your ERP. They need to convince one person on your AP team that a routine banking change is legitimate. In organizations processing hundreds of vendor payments monthly, these requests don't get the scrutiny they deserve because they look like normal business operations.

The defense isn't better email filters, though those help at the margin. The defense is removing the human judgment step from vendor banking verification entirely. Payment platforms that maintain independently verified vendor banking records can flag any requested change against their own database before a payment is released. If the banking details don't match what the platform has verified independently, the payment pauses automatically.

What Payment-Level Controls Close the Gap for Intacct Users?

The controls that address payment fraud operate in a different layer than ERP security. They sit between invoice approval and payment release, adding verification steps that ERPs weren't built to perform.

How do virtual cards eliminate check fraud exposure?

Virtual cards generate a unique, single-use card number for each payment. The number can only be used once, for the exact approved amount, by the specified vendor. If someone intercepts the payment information, it's worthless because the number has already been used and locked.

This eliminates check fraud entirely for every vendor enrolled in your virtual card program. It also reduces the risk of vendor impersonation fraud because the payment is tied to a specific vendor's verified enrollment, not to a banking detail that could be changed through a compromised email.

The trade-off is that not every vendor accepts card payments. Enrollment coverage depends on active outreach to your vendor base, which is why managed enrollment services matter for fraud prevention as much as they matter for rebate revenue.

What does validated vendor banking actually look like in practice?

Validated vendor banking means the payment platform maintains its own verified database of vendor banking details, independent of what's in your ERP. When a vendor's banking information changes, the platform verifies the change through its own channels before routing any payments to the new account.

In practice, this means your AP team can update vendor records in Sage Intacct as part of their normal workflow, but the payment platform cross-references that information against independently verified data before releasing funds. If there's a mismatch, the payment is held for review instead of sent to a potentially fraudulent account.

This is fundamentally different from an ERP audit trail, which records the change after it happens. Validated banking prevents the bad payment before it happens.

How Does Corpay Help Sage Intacct Users Prevent Payment Fraud?

Corpay's payment automation platform adds the fraud prevention layer that Sage Intacct's native controls don't cover.

Specifically, Corpay adds validated vendor banking across a network of 4M+ accepting vendors. When vendor banking details change, Corpay's managed service team independently verifies the change before any payment routes to the new account. This removes the BEC attack vector where a fraudster redirects payments by spoofing a vendor banking change request.

For check fraud prevention, Corpay's virtual card program assigns a unique, single-use card number to each payment. Every payment enrolled in the virtual card channel is immune to check interception, alteration, and the account number exposure that makes checks inherently vulnerable.

The managed exception handling matters too. When a payment is flagged for anomalies, a review of payment pattern deviation, unusual amounts, or timing, Corpay's team handles the investigation and resolution. Your AP team gets notified of outcomes rather than managing the triage process.

Frequently Asked Questions

These are the fraud-related questions that come up most often from Sage Intacct users evaluating their payment security posture, drawn from community discussions, audit reviews, and conversations with finance teams running Intacct.

How secure is Sage Intacct?

Sage Intacct's application security is strong. The platform holds SOC1, SOC2, PCI, HIPAA, and ISO 27001 certifications. It offers role-based access controls, multi-factor authentication, SSO, encrypted data at rest and in transit, and detailed audit trails. The security gaps aren't in the application itself but in the payment execution and vendor verification layers that sit outside the ERP.

Can Sage Intacct detect payment fraud?

Intacct can detect some internal fraud patterns through audit trails, transaction security rules, and its 2026 R1 AI-powered anomaly detection for invoice processing. It cannot detect external payment fraud like BEC, vendor impersonation, or check fraud because these attacks target workflows outside the application. Detecting those requires payment-layer controls like validated vendor banking and automated anomaly flagging on outbound payments.

What is the most common type of payment fraud in accounts payable?

Check fraud is the most common type by frequency, according to AFP's 2025 survey. BEC is the costliest by dollar amount. Invoice manipulation and vendor impersonation round out the top categories. Each requires different controls, and no single tool prevents all of them.

How do virtual cards prevent payment fraud?

Virtual cards generate a unique, single-use number for each payment that can only be used once, for the exact approved amount, by the specified vendor. This eliminates check fraud entirely for enrolled vendors and significantly reduces vendor impersonation risk because payments are tied to a verified vendor enrollment, not to a changeable banking detail.

What should AP teams do after a BEC attack?

Contact your bank immediately to attempt a wire recall or payment reversal. Notify law enforcement (FBI's IC3) and your insurance provider. Audit all recent vendor banking changes for other compromised records. Then implement preventive controls: validated vendor banking through a payment platform, mandatory out-of-band verification for banking changes, and virtual card payments to eliminate static account number exposure.

Does Sage Intacct support two-factor authentication?

Yes. Sage Intacct supports both two-step verification (MFA) and single sign-on (SSO) integration. MFA adds a second authentication factor beyond username and password, which protects against credential theft. However, MFA protects system access, not payment execution. A team member with valid MFA credentials can still be tricked by a BEC attack into sending a payment to a fraudulent account.

Nick Herrick

Director of Strategic Sales

Nick Herrick is a Director of Strategic Sales with nearly 20 years of experience spanning financial services, corporate finance, and technology. He guides organizations to implement critical initiatives, optimize operations, and enhance profitability.

AP Automation