What will IT ask when finance proposes an AP automation tool?

Expect questions on: SOC 1 (financial-reporting controls relevant because AP touches the ledger) vs SOC 2 (security/availability), and Type II (controls tested over time) over Type I (point-in-time); encryption in transit and at rest, data residency, subprocessor list, breach history, and pen-test cadence; SSO/SAML with MFA enforcement and ideally SCIM provisioning so access deprovisions with HR; and on the ERP connection, the auth method, the scopes/permissions granted, least-privilege design, and how tokens are stored. Bring the vendor's trust/security documentation to the first IT meeting.

For a cloud AP tool the internal lift is usually modest: authorize the ERP integration (sender ID/OAuth/app install), configure SSO, support sandbox testing, and sign off - far lighter than an on-prem integration that needs servers, agents, and network changes. Clarify who "maintains" the integration after go-live (vendor, partner, or your IT) and what "maintained" includes when the ERP updates - that ownership question is the one most likely to cause finger-pointing later, so settle it in the contract.

SOC 1 covers controls over financial reporting (relevant because AP feeds the ledger); SOC 2 covers security, availability, and related trust criteria. Type I attests controls at a point in time; Type II attests they operated effectively over a period (usually 6-12 months). For finance software touching the GL, require SOC 2 Type II at minimum, and SOC 1 where it affects financial-reporting controls.

Encryption in transit and at rest, data residency/location, the subprocessor list, breach/incident history and notification commitments, penetration-testing cadence and remediation, access controls, and data-handling/retention. A vendor that answers these readily with current documentation is showing operational maturity; evasive answers are the red flag.

SSO/SAML centralizes authentication and lets IT enforce MFA and disable access in one place when someone leaves. Verify SAML support, MFA enforcement, and SCIM provisioning (so accounts auto-deprovision via your identity system) - orphaned finance-tool accounts after offboarding are a real audit and security exposure.

The authentication method (OAuth/service account/API key), the scopes and permissions granted, whether it follows least privilege (only what AP needs, not admin-everything), and how credentials/tokens are stored and rotated. The connection is the most sensitive part of an AP tool's footprint - IT will scrutinize it most.

Cloud: authorize the integration, configure SSO, support sandbox testing, sign off - light. On-prem (or on-prem ERP needing an agent): provision a server/agent, open network paths, manage updates - heavier. Set IT's expectation to the right tier so the lift isn't over- or under-estimated.

Test the full path on your own ERP: master-data refresh, coding with every dimension, validation on closed periods/invalid combinations, a forced posting failure and retry, PO matching with partials and variances, multi-entity posting, and month-end volume. Sign-off criteria: clean posts, intelligible errors with retry, correct entity/dimension fidelity, and acceptable performance at peak.

Could be the vendor (preferred for native connectors), an implementation partner, or your IT (for custom builds). "Maintained" should explicitly include keeping the connector working through ERP updates, monitoring connection health, and fixing breakages within an SLA. Pin this down contractually - ambiguity here is what produces the vendor-vs-partner blame loop.

Most are: missing a SOC report (request it), SSO not configured (it's supported, just turn it on), unclear data residency or subprocessors (get the documentation), or over-broad API scopes (tighten to least privilege). Genuinely unfixable vetoes are rare - usually it's a documentation or configuration gap. Re-engage with the specific objection and the vendor's security team.

Confirm before signing that you own your data, can export invoices, images, coding, and the audit trail in usable formats, and what the egress terms and timelines are at contract end. "How do we leave?" is a fair due-diligence question; a confident vendor answers it plainly.

Require a defined uptime SLA with credits and a status/incident-communication commitment, and ask the business-continuity question: if the tool is down at a payment run or close, what's the fallback? A mature vendor has both an availability track record and a continuity answer.

Whether the vendor trains models on your data (and how to opt out), where LLM calls go and under what data-protection terms, what's redacted before any model sees it, and how AI outputs are governed. For finance data, "does our data train your models and where does it go?" is the essential question.

Minimal viable diligence: require SOC 2 Type II, confirm SSO/MFA and encryption, get the subprocessor list and breach history, verify data-export/exit terms, and check least-privilege ERP scopes. These five cover most real risk; you don't need a security org to ask for a SOC report and read it.

That roles enforce least privilege, that incompatible duties are separated (e.g., the person who enters/approves an invoice can't also release its payment), and that the system records who did what immutably. SoD enforced by the tool's design - not by policy memo - is what auditors want to see.

Stampli is built as enterprise finance SaaS - ERP-native integrations via API, bridge, or file with the connector maintained by Stampli, role-based access and segregation of duties enforced by design, an immutable audit trail, and the security attestations and SSO IT expects from a system that touches the ledger. Implementation pairs each customer with a dedicated consultant who is both an ERP specialist and an accounting professional, with typical go-live in weeks, so the internal IT lift is scoped and supported rather than open-ended.