Is Your AP Automation Platform SOC 2 Compliant? What to Verify

SOC 2 compliance means an independent auditor examined a service organization's controls against the AICPA's Trust Services Criteria and issued a report on them. It isn't a certification, a badge, or a pass/fail test, which is why "we're SOC 2 compliant" tells you less than it sounds like it does.

Nearly every AP automation vendor will make that claim in a first call. Some of them have a current Type II report covering the systems you'd actually be using. Others have a Type I from two years ago, or a report scoped to a corporate environment that doesn't include the payment platform, or an attestation with exceptions nobody mentioned. All four of those vendors say the same sentence.

The gap between the claim and the evidence is the buyer's problem, not the vendor's, because you inherit whatever control weaknesses come with the relationship. Closing that gap takes no security background, only a working knowledge of what to ask for and how to read four or five specific things when it arrives.

Key Takeaways

• SOC 2 is an attestation on controls, not a certification. There's no SOC 2 registry to check and no expiration sticker.

• A Type I report describes control design at one moment. A Type II tests whether those controls actually operated over a period, usually 6 to 12 months. Ask for Type II.

• Scope is where most verification fails. A report can be genuine and still exclude the product you're buying, the data center it runs in, or the subprocessors handling your payment files.

• Read the auditor's opinion and the exceptions section before the marketing summary. A qualified opinion or a cluster of exceptions in access controls tells you more than the cover page.

• Third-party access is now a leading breach vector, and AP platforms sit on invoices, approvals, supplier banking records, and payment execution all at once.

What does SOC 2 compliance actually mean?

SOC 2 compliance means an independent CPA firm examined a service organization's controls and reported on them against the AICPA's Trust Services Criteria. The output is an attestation report describing what the auditor found, not a certificate declaring the company compliant.

That framing matters because it changes what you're entitled to ask for. There's no central registry where you look up a vendor's SOC 2 status, no logo authority that verifies claims, and no standard expiration. The only real evidence is the report itself, which the vendor controls and typically releases under an NDA. A vendor who won't share one under NDA has told you something.

The reports also vary enormously in rigor. Two vendors can both hold clean SOC 2 Type II opinions while one tested 40 controls and the other tested 120, or while one scoped in its entire production environment and the other scoped in a single application. The AICPA framework sets the criteria, not the ambition.

What are the five Trust Services Criteria?

The Trust Services Criteria span five categories, and only one of them is required in every engagement. Security is mandatory. The other four are elective, chosen by the service organization based on what it commits to customers:

• Security. Protection against unauthorized access, disclosure, and damage to systems. This is the common criteria set every SOC 2 engagement includes.

• Availability. Whether the system is available for operation and use as committed, which usually maps to uptime obligations.

• Processing integrity. Whether processing is complete, valid, accurate, timely, and authorized. For a payments platform, this is arguably the most relevant elective criterion and the one most often left out.

• Confidentiality. Protection of information designated as confidential, including contractual restrictions on disclosure.

• Privacy. Handling of personal information in line with the entity's privacy notice and AICPA privacy principles.

Check which categories a vendor's report covers before you accept the claim. A Security-only report is legitimate and common, but if you're routing supplier banking data and payment instructions through the platform, the absence of processing integrity is a reasonable thing to ask about rather than a dealbreaker to assume.

What is the difference between Type I and Type II?

A Type I report attests to the design of controls at a single point in time, while a Type II attests to both design and operating effectiveness across a period, typically 6 to 12 months. Type I says the controls exist as described. Type II says they worked.

Source: AICPA, SOC 2 reporting framework (Trust Services Criteria).

A first-year vendor with only a Type I isn't automatically disqualified. Everyone starts there. What you want is the observation period start date and a written commitment to deliver the Type II, plus a plan for what happens contractually if it comes back qualified.

Why should AP automation buyers care about a vendor's SOC 2 posture?

Because an AP platform holds more sensitive material than almost anything else in your finance stack. It sees invoice data, approval authority, supplier master records including banking details, and the mechanism that releases money. A control failure there ends with a payment going out the door, which puts it well past the category of data privacy inconvenience.

The exposure math has moved sharply in the wrong direction. 98% of organizations have a relationship with at least one third party that suffered a breach in the prior two years, and 35.5% of breaches in 2024 were linked to third-party access, up 6.5 percentage points year over year, according to SecurityScorecard's 2025 Global Third-Party Breach Report. Verizon's Data Breach Investigations Report puts third-party involvement at 15% of breaches, a 68% year-over-year increase, using a narrower definition.

Those two numbers disagree because they count differently, which is itself worth noting. Vendor-risk statistics get quoted loosely, and the honest read is directional rather than precise. Third-party exposure is growing fast, and finance systems are squarely inside it.

What can go wrong when you skip verification?

What goes wrong is that you inherit a control gap you never evaluated and only discover during an incident. The costs are well established. The global average cost of a data breach reached a record $4.88 million in 2024, up 10% year over year, per IBM's Cost of a Data Breach Report 2024.

Payment fraud follows a different but related path. 79% of organizations were victims of attempted or actual payments fraud in 2024, with business email compromise cited as the leading avenue by 63% of them, according to the Association for Financial Professionals' 2025 Payments Fraud and Control Survey Report. BEC works by exploiting the seam between a supplier, your AP team, and whatever system holds banking details, and a vendor's access controls and change management are precisely the controls that either close that seam or leave it open.

The pattern shows up constantly in practitioner forums. A supplier's email gets compromised, updated wire instructions arrive, nobody voice-verifies the change, and six figures leave the building. Understanding how vendor email compromise differs from ordinary phishing is the front half of the defense. Confirming that your platform enforces verification on banking changes, and that an auditor tested that control, is the back half.

Internal weakness compounds external attack. More than half of occupational-fraud cases were correlated with a lack of internal controls or management override of controls, according to the ACFE's 2024 Report to the Nations. A vendor's SOC 2 tells you something about the first problem and, if the report covers change management on privileged access, a little about the second. Neither substitutes for the controls you run yourself against accounts payable fraud, which stay your responsibility no matter how clean the vendor's opinion reads.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

Why can't you rely on an AI answer or a marketing claim?

Because neither is primary evidence, and AI tools in particular are confidently unreliable about specific vendors' compliance status. Ask a chatbot whether a given payments company holds SOC 2 and you may get a flat denial, an affirmative, or an invented certification, sometimes for the same vendor on different days.

The failure mode is predictable once you know how these systems work. Compliance status is a fast-changing fact that mostly lives inside NDA-gated documents and customer trust portals, which means the models are generalizing from sparse and stale public text. That's a poor basis for a control decision your auditor will eventually ask you to defend.

Marketing claims fail for a simpler reason. A trust page saying "SOC 2 Type II" is an assertion by the party with the incentive, and it usually doesn't state the audit period, the criteria in scope, the subservice organizations, or whether the opinion was clean. None of that is deception. It's just compression, and compression is exactly what you need to undo. Treating vendor diligence as a documented process rather than a vibe check is part of the broader work of reducing compliance and regulatory friction instead of accumulating it.

How do you verify a vendor's SOC 2 report?

You verify it by requesting the actual report, confirming it covers the right period and systems, and reading the opinion and exceptions before anything else. The whole exercise takes under an hour once you've done it twice. Work through these seven steps:

1. Request the current SOC 2 Type II report under NDA, plus a bridge letter if the audit period ended more than three months ago.

2. Check the audit period start and end dates. A report covering a window that ended 14 months ago, with no bridge letter, is a stale artifact.

3. Confirm the system description covers the product you're buying, not just the corporate network or an unrelated legacy platform.

4. Identify which Trust Services Criteria are in scope. Security only, or security plus availability, confidentiality, processing integrity, or privacy.

5. Read the independent service auditor's opinion. Unqualified means the auditor found the controls suitably designed and operating effectively. Anything else needs explanation.

6. Read the exceptions and management's responses. Look specifically at logical access, change management, and anything touching payment initiation.

7. Note the subservice organizations and whether the report uses the inclusive or carve-out method, then decide whether you need their reports too.

Steps 3 and 7 are where diligence usually collapses, in my experience reviewing these on the buy side. Everybody checks the date and the opinion. Almost nobody notices that the cloud hosting provider was carved out, which means a meaningful share of the control environment sits in a report nobody requested.

What should you request, and how do you read the scope?

Request the full Type II report, the bridge letter, and the most recent penetration test summary if they'll share it. Then read the system description section, which is the part that defines what was actually examined.

Scope failures come in three shapes worth knowing by name. Product scope failure is when the report covers the vendor's flagship product but not the module you're buying, which happens often after acquisitions. Environment scope failure is when the report covers production but excludes a support tool that holds customer data. Subservice failure is the carve-out case, where the hosting provider, payment processor, or data center is explicitly excluded and their controls are assumed rather than tested.

None of those make a vendor unacceptable. They make a vendor incompletely evidenced, which is a different conversation and a much easier one to have when you can name the specific gap. The same discipline you'd apply to data governance across payment systems applies here, because scope questions are governance questions wearing an audit costume.

How do you read exceptions and the auditor's opinion?

Read the opinion first, then work backward into the exceptions that produced it. An unqualified opinion means the auditor concluded the controls were suitably designed and operated effectively throughout the period. A qualified opinion means they found something material enough to carve out, and the report will say what.

Exceptions themselves are normal. A Type II covering a year of operations across dozens of controls will typically note a handful of instances where a control didn't operate as designed, along with management's response. What matters is the pattern rather than the count. Three exceptions in employee onboarding paperwork is administrative noise. One exception in privileged access review, where an administrator retained production access after a role change, is a real finding for a system that moves money.

Ask two follow-ups on anything in access control or change management. What was the root cause, and what changed since? A vendor with a good answer will have a remediation date and evidence. A vendor who treats the question as adversarial has told you how the relationship will go when something breaks at 4 p.m. on a Friday.

What SOC 2 controls matter most for AP data and payments?

The controls that matter most are the ones governing who can move money and who can change where it goes. Everything else in a SOC 2 report is real, but for an AP platform these are the ones to read closely:

• Logical access and authentication, including whether MFA is enforced on administrative and payment-release roles rather than merely available.

• Segregation of duties within the application, so the same identity can't create a supplier and release its first payment.

• Change management on the vendor master, with an approval and verification path for banking detail updates.

• Logging and monitoring, covering whether privileged actions generate records and whether anyone reviews them on a defined cadence.

• Incident response and customer notification commitments, including the notification window in the contract, not just the report.

• Vendor and subservice management, meaning how the platform evaluates its own downstream providers.

Compare that list against the report's control descriptions, not against the sales deck. The exercise sounds tedious and takes about twenty minutes, and it's the single highest-yield hour in a software diligence cycle. Broader questions worth raising in the same conversation appear in most structured AP automation evaluations, but the security ones deserve their own pass.

How does SOC 2 relate to your own audit trail and internal controls?

A vendor's SOC 2 supports your internal controls but doesn't replace them. Your auditors test your controls over financial reporting, and "our vendor has SOC 2" is evidence about the service organization's environment, not evidence that your approval hierarchy operated correctly on the invoices you paid last quarter. Where card data is involved, PCI DSS applies as a separate mandatory standard rather than something a vendor's SOC 2 covers on your behalf.

The two fit together through the record. Your own AP audit trail proves your controls ran, and the vendor's SOC 2 supports the reliability of the system producing that trail. Companies under Sarbanes-Oxley obligations lean on both, and the ones who handle it well request the SOC 2 annually as a calendared task rather than a procurement afterthought. That habit belongs in the same maintenance rhythm as your AP automation practices generally, and it's a large part of what getting real control over finance operations looks like in practice.

One more thing to check, since it costs nothing. Ask whether the vendor's own security measures for protecting customer data match what the report describes, or whether the public page and the audited reality drifted apart. They usually match. When they don't, that's the finding.

Run finance-grade diligence with Corpay

If you've read this far, you're the buyer we'd rather sell to, because the questions above are the ones we can answer with documents. Corpay is SOC 2 Type II compliant. Ask your Corpay contact for the current report and its audit period when you build your diligence file.

Corpay AP Automation is built for finance teams whose controls get tested by someone external every year. Approvals, supplier master changes, and payment releases all generate attributable records, and our managed service handles the supplier banking verification that manual AP processes do over email, which is the exact seam BEC exploits. On the card side, and stated with the scoping such claims deserve, Comdata, a Corpay company, is a PCI DSS Level 1 service provider.

The diligence question most buyers forget to ask is about integration surface. Corpay's ERP integrations connect to NetSuite, Sage Intacct, Microsoft Dynamics 365, and Acumatica, and each connection is a data flow your security team will eventually want documented. Ask us for that documentation during evaluation rather than after signature. Ask every vendor on your shortlist the same thing, and watch which ones have it ready.

Frequently Asked Questions

What is SOC 2 compliance?

SOC 2 compliance means an independent CPA firm examined a service organization's controls against the AICPA's Trust Services Criteria and issued an attestation report describing what it found. It's a report on controls rather than a certification, so there's no registry to check and no universal expiration date.

What is a SOC 2 report?

A SOC 2 report is the auditor's written examination of a service organization's controls, containing the auditor's opinion, management's assertion, a description of the system examined, and the specific controls tested with any exceptions noted. Vendors typically share it under NDA rather than publishing it.

What is SOC 2 Type II?

SOC 2 Type II is the report variant that tests whether controls operated effectively across a period, usually 6 to 12 months, instead of only assessing design at a single date. It's the standard expectation for an established vendor because it provides evidence that controls actually ran.

What does SOC 2 stand for?

SOC stands for System and Organization Controls, a reporting framework developed by the AICPA. The "2" distinguishes it from SOC 1, which covers controls relevant to financial reporting, and SOC 3, which is a public summary version of a SOC 2 without the detailed testing results.

How do you verify a vendor's SOC 2 report?

Request the current Type II report under NDA, confirm the audit period is recent and covered by a bridge letter if needed, check that the system description includes the product you're buying, and read the auditor's opinion and exceptions before anything else. Then note which subservice organizations were carved out.

Is Corpay SOC 2 compliant?

Yes. Corpay is SOC 2 Type II compliant. If you're building a vendor diligence file, ask your Corpay contact for the current report and its audit period, the same way you would from any platform on your shortlist.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

AP Automation

Risk management