AR Automation and SOC 2: What Finance and Security Owe Each Other

Buying AR automation used to be a finance decision. Now it is a security decision that finance runs. Customer data leaves your accounting system, payment activity generates its own audit trail, and every touch between your AR team and a customer flows through a third-party system.

Here is what finance and security actually need to agree on, and what the compliant version of AR automation looks like.

What is the AR data footprint from a SOC 2 perspective?

An AR automation platform, at minimum, holds:

• Customer master data. Names, billing contacts, email addresses, phone numbers. Sometimes company hierarchies.
• Invoice data. Amounts, due dates, PO numbers, line items, payment history.
• Communication logs. Every reminder sent, every reply received, every promise to pay logged.
• Payment metadata. Not card numbers or bank account numbers (that stays with the processor), but transaction identifiers, amounts, and timing.
• User activity. Who sent what, who approved what, who accessed which customer record.

Each of these has SOC 2 implications. Customer master data is confidential information; invoice data is financial data; communication logs are potentially subject to legal discovery; payment metadata connects to your payment processor's own compliance stack.

The right posture is to treat the AR platform as a fully in-scope system for your own SOC 2, not as a peripheral tool.

What should you require from the vendor?

The minimum bar for any AR automation vendor you would put into production.

Vendors who cannot produce these documents inside a week of asking are not ready for mid-market B2B. Vendors who can produce them but have caveats in the shared responsibility model deserve careful reading.

How should the accounting system integration be secured?

Three specific things to require, in writing.

• OAuth 2.0 with token rotation. Not username and password. Not shared API keys. OAuth means you can revoke access at any time and rotate credentials without changing anything on the vendor side.
• Least-privilege API scopes. The AR tool should request only the specific endpoints it uses: read invoices, read payments, write payment application, read customer data. If it requests broader scopes ("read all financial data"), question why.
• Read-write separation where possible. For the initial 30 days, run the integration in read-only mode. Confirm data flows are what you expect before enabling write-back to the ledger.

The write-back path is the highest-risk part of the integration. Payment application, credit memo creation, and reconciliation touch the GL directly. A misconfigured write-back can corrupt your accounting records in ways that take weeks to unwind.

What role-based access controls should you configure?

Inside the AR platform itself, four roles cover most needs.

• Viewer. Read-only access to invoices, aging, and forecasts. Appropriate for FP&A analysts, executives, and internal audit.
• Sender. Can trigger dunning sequences, log promises to pay, and manage the collection queue. Appropriate for the AR team.
• Approver. Can approve dispute resolutions, credit holds, and write-offs above a threshold. Appropriate for the AR lead and controller.
• Admin. Can configure sequences, add users, and modify integration settings. Should be limited to two people, ideally one in finance and one in IT or security.

Two governance rules that matter.

• Quarterly access reviews. Finance owner and security owner sit together, review the user list, and confirm each role assignment. Anyone who has changed teams or left the company gets removed.
• Separation of duties. No single user should be able to both send a reminder and mark an invoice paid. This is a basic financial control that also matches SOC 2 requirements.

How do disputes and legal holds interact with AR automation?

This is the area where finance and legal need to talk before signing an AR tool.

• Communication retention. Every dunning email your platform sends is a business communication that may be discoverable. Retention policy should match your general email retention policy, and the platform should support legal hold on specific accounts.
• Dispute documentation. When a customer flags a dispute in the portal, that record becomes part of the audit trail for how the dispute was handled. Ensure the platform captures timestamps, resolution notes, and status changes with immutable logs.
• Payment application. When a partial payment is applied to a disputed invoice, the audit trail should show exactly who applied it and why. This matters for both financial controls and potential litigation.

Ask the vendor for a walkthrough of what a legal hold actually looks like in their system. If they cannot demonstrate a working legal hold in a demo, they are not ready for regulated industries or for any customer with real litigation exposure.

What is the annual review checklist?

Once a year, finance and security should run through this together.

1. Confirm the vendor's SOC 2 Type II is current. Attestation reports are annual; a report older than 15 months is stale.
2. Review the subprocessor list. New subprocessors added since last review need to be evaluated.
3. Run an access review. Every user, every role, confirmed in writing.
4. Review the audit log. Sample 5% of sends, approvals, and admin actions for reasonableness.
5. Confirm data retention alignment. Retention on the platform should match your policy.
6. Test the exit clause. Confirm you can export data and force deletion, at least in principle.

Skipping this review for two consecutive years is how compliant vendors become non-compliant on your books without anyone noticing.

Does this actually improve security, or just shift it?

For most mid-market finance teams, moving from manual AR to a compliant automation platform is a net security improvement.

Consider what manual AR looks like from a security standpoint.

• CSV exports. Customer contact data and invoice details sitting in Downloads folders, emailed to auditors, shared in Slack.
• Shared inboxes. Dunning correspondence in accounts@ that anyone on the team can read, with no audit trail of who sent what.
• Spreadsheet trackers. Payment history, credit terms, and contact data in Google Sheets shared with "anyone at company can view."
• No encryption at rest. Customer data on individual laptops.
• No user activity logs. Impossible to reconstruct what happened during an incident.

A compliant AR platform replaces all of that with centralized data, encryption, access controls, and audit logs. The security improvement is real, and it is often the argument that gets the security team on board.

The mistake to avoid

Two mistakes. First, treating AR automation as a finance-only decision and skipping security review, which turns a routine procurement into a post-hoc scramble when the vendor questionnaire arrives. Second, treating it as a security-only decision and demanding controls that make the tool unusable for the AR team. The right posture is joint ownership: finance owns the operational fit, security owns the risk controls, and they agree on a shared responsibility model before signing. Compliant AR automation is not harder than compliant anything else; it just needs both teams in the room from day one.