SOC 1 Report for AI Vendors: What Finance Should Ask

A clean SOC report can still leave the AI out of scope. Before an AI tool touches your bank recs or journal entries, here is how to tell whether the vendor's SOC report covers the parts your auditor will actually lean on.

TL;DR: Ask an AI accounting vendor for a SOC 1 Type 2 report if its output feeds your financial statements, and a SOC 2 Type 2 for security. Then check three things: whether the AI model provider is carved out, whether model changes fall under tested change management, and which user controls you must run yourself.

Which SOC report should finance ask an AI vendor for?

A SOC report is an independent CPA firm's report on the controls at a service organization, prepared under AICPA attestation standards. Three versions matter when you evaluate an AI accounting vendor:

• SOC 1: covers controls at the vendor that are relevant to your internal control over financial reporting (ICFR). This is the report your external auditor reads. The AICPA describes it in its SOC 1 Guide.
• SOC 2: covers controls relevant to security, availability, processing integrity, confidentiality and privacy, the five Trust Services Criteria categories. IT, security and procurement usually ask for this one.
• SOC 3: a short, general-use version of a SOC 2 with no test details. Fine for a website badge, not for your audit file.

Each report comes as a Type 1 or a Type 2. A Type 1 report says the controls were suitably designed as of a single date. A Type 2 report says they were designed and operated effectively over a period, and it lists the tests the auditor ran and what they found. For anything that feeds the general ledger, the Type 2 is the one that gives your auditor evidence of operation.

A short way to remember it: SOC 1 answers "can my auditor rely on this vendor?" SOC 2 answers "is my data safe with this vendor?"

Here is how each report maps to an AI accounting tool:

• SOC 1 Type 2: Covers ICFR-relevant controls, tested over a period; Read by your external auditor and controller; Needed when AI output feeds the GL (reconciliations, journal entries, invoice coding).
• SOC 1 Type 1: Covers design only, as of one date; Read by your auditor and controller; A first-year stopgap, not evidence that controls operated.
• SOC 2 Type 2: Covers security plus any of availability, processing integrity, confidentiality and privacy the vendor scoped in, tested over a period; Read by IT, security and procurement; Needed for any tool that holds your bank or ledger data.
• SOC 2 Type 1: Covers design only, as of one date; Read by IT and procurement; Common for early-stage vendors.
• SOC 3: A public summary with no tests listed; Read by anyone; Marketing only.

Why doesn't a clean SOC report always cover the AI?

An unqualified opinion says the controls in scope worked. It does not say the AI was in scope. Three gaps recur.

1. The criteria were not written for AI. The Trust Services Criteria behind SOC 2 date to 2017, with revised points of focus in 2022. Aprio's September 2026 analysis puts it plainly: the criteria didn't change, but auditors now apply them to AI governance, model versioning, output monitoring and vendor oversight. A Cloud Security Alliance research note (August 30, 2026) adds that the AICPA has not published AI-specific criteria, so two AI vendors can each hold a clean SOC 2 report while having tested different controls.

2. The model provider may be carved out. Many AI accounting tools call a language model hosted by another company. In SOC terms, that company is a subservice organization. Under the carve-out method, the report describes the subservice organization but excludes its controls from testing. Under the inclusive method, its controls are tested as part of the report. If the model provider is carved out, the vendor's report says nothing about how that model is changed or monitored. You need the provider's own report.

3. The vendor chooses the scope. The vendor decides which systems and control objectives go into the report. A SOC 2 scoped to security alone says nothing about whether a proposed bank match is accurate. Processing integrity, the category about processing that is complete, valid, accurate, timely and authorized, is optional.

A SOC report covers what the vendor put in scope, for the period tested. Everything else is still a question you have to ask.

Want every AI match to come with the source rows, the rule and the SQL behind it, so your auditor can check the output directly? Join the Yoraito waitlist for early access.

What should finance ask an AI vendor about its SOC report?

Send these ten questions before you sign. They work alongside our 12 audit trail questions for AI accounting software RFPs, which cover the product itself.

• 1. Report and period: Which report and type do you have, and what period does it cover? A Type 2 period should overlap your fiscal year.
• 2. SOC 1 availability: Do you have a SOC 1, and which control objectives touch transaction processing such as matching, coding and posting?
• 3. Processing integrity: Is processing integrity in scope for your SOC 2?
• 4. Subservice organizations: Which subservice organizations are listed, and is each one carved out or inclusive? Is the AI model provider one of them?
• 5. Model provider assurance: If the model provider is carved out, can you share its own report, and how do you monitor it?
• 6. Model changes: Is a change of model, model version or prompt treated as a system change under the change management controls that were tested?
• 7. Exceptions: Did the auditor note any exceptions, and what was management's response?
• 8. User controls: Which complementary user entity controls (CUECs) does the report expect us to run?
• 9. Bridge letter: Will you give us a bridge letter for the gap between your report end date and our year-end?
• 10. Other attestations: Do you hold or plan other AI-related attestations, such as ISO/IEC 42001 certification?

Two of these need context. A bridge letter covers the gap between a SOC report's end date and your year-end. Linford & Co notes it is signed by the vendor's management, not the service auditor, and typically covers no more than three months. ISO/IEC 42001 is a management system standard for AI. It is useful context, but Baker Tilly notes that ISO 42001 and the NIST AI RMF have not been formally incorporated into SOC 2, so treat it as a supplement, not a substitute.

How do you read an AI vendor's SOC report once you have it?

Most reports follow the same order. Here is what to check in each part and the red flag to look for:

• Auditor's opinion: Look for an unqualified opinion. Red flag: a qualified opinion, or an adverse opinion or disclaimer.
• Management's assertion: Confirm the system described is the product you are buying. Red flag: your product or module is not named.
• System description: Find the subservice organizations, the carve-out or inclusive method, and the CUECs. Red flag: the model provider is carved out and no separate report is offered.
• Control objectives and test results: Read every exception, not just the summary. Red flag: exceptions in change management or logical access, the controls that protect the AI's logic.

A worked example

A controller reviews an AI reconciliation vendor's SOC 1 Type 2. The control objective "Changes to matching logic are authorized, tested and approved before deployment" was tested with no exceptions. Good. But the system description lists the language model provider as a carved-out subservice organization, and one CUEC reads: "User entities review and approve exceptions proposed by the system."

The conclusion for the review memo has three parts. The vendor's own rule changes are covered. The model provider's changes are not, so ask question 5. And your team's review of AI-proposed matches is now a control you must run and evidence. If your auditor will lean on that CUEC, you need a log that proves it happened. A query like this one, run against your review records, is one way to show it:

-- Evidence for the CUEC "user entities review AI-proposed matches"
SELECT p.match_id, p.proposed_at, p.model_version,
r.reviewer_id, r.reviewed_at
FROM ai_proposed_matches p
LEFT JOIN match_reviews r ON r.match_id = p.match_id
WHERE p.period = '2026-09'
AND (r.reviewer_id IS NULL OR r.reviewed_at < p.proposed_at);
-- Zero rows: every proposal had a named reviewer after it was proposed.

This evidence belongs in your year-end file; see PBC list reconciliations auditors accept.

What if the AI vendor doesn't have a SOC report yet?

This is common with young vendors. The Cloud Security Alliance note estimates a first-year SOC 2 Type 2 for an AI startup takes six to fourteen months and tens of thousands of dollars. A missing report is not an automatic no, but it moves work to you:

• Ask for the plan: Is there a Type 1 or a readiness assessment, and when does the Type 2 observation period start?
• Talk to your auditor early: PCAOB AS 2601 sets out how auditors consider a company's use of a service organization. Ask whether your auditor will want to test anything at the vendor directly, before year-end, not during fieldwork.
• Strengthen your own controls: Review every AI-proposed entry before it posts, keep the reviewer and timestamp, and reperform a sample each month.
• Prefer output you can reperform: If each AI result comes with its source rows, the rule it applied and the query behind it, your auditor can check the work without relying on the vendor's controls at all.

That last point is the idea Yoraito is built around: SQL-first, auditable AI where the evidence travels with the output, so a SOC report supports your controls instead of replacing them. A 30-day trial run is a good place to test this; our AI accounting pilot scorecard includes audit trail checks you can run on any vendor. For more on what auditors ask about AI-assisted reconciliations, see 9 questions your auditor will ask.

FAQ

Is a SOC 2 report enough for an AI accounting tool?

Not always. A SOC 2 covers security and any optional categories the vendor scoped in. If the tool's output feeds your general ledger, your external auditor will usually want a SOC 1 Type 2, or will need to rely more on your own review controls.

What is the difference between a SOC 1 Type 1 and a Type 2?

A Type 1 report covers whether controls were suitably designed as of one date. A Type 2 report covers whether they were designed and operated effectively over a period, and it lists the auditor's tests and results.

What does carve-out mean in a SOC report?

Carve-out means a subservice organization, such as a cloud host or AI model provider, is described in the report but its controls were not tested. You need that organization's own report to cover the gap.

What is a bridge letter?

A bridge letter is a statement from the vendor's management covering the gap between the SOC report's end date and your fiscal year-end. It typically covers up to three months and does not replace the report.

What's the next step?

Send the ten questions above to every AI vendor that touches your ledger, and note the answers, including any carve-outs and CUECs, in your vendor file before year-end planning starts. To hear when Yoraito opens up, join the waitlist.