How We Build Finance Automations
This page is written for the person who has to review us. If your finance team is considering an automation partner and it has landed on your desk to assess, this sets out how we handle credentials, what the audit trail gives you, how errors behave, how changes are controlled, and how we decide between an API integration and RPA. No marketing claims, and nothing you would otherwise have to ask for in a questionnaire.
Least privilege, named accounts
One service account per integration, scoped to the objects it touches, documented at handover
No credentials in code or config
Secrets live in a managed store. We never ask for a named user's password
Failure is loud and attributable
Bounded retries for transient faults, no retry for validation failures, alerting on the run that never started
Changes go through a release
Posting logic, matching rules and thresholds are versioned and reviewed. Nothing is edited live
Finance Automation Security and Controls at a Glance
The short version, for a reviewer who needs an answer before a meeting. Each item is expanded further down.
Access and Credential Handling
The first question a security reviewer asks is what we will have access to and how that access is held. These are our standard, not an upgrade available on request.
What we ask for
A dedicated service account in each system in scope, created by you, with permissions scoped to the objects the integration reads and writes. A non-production instance for build and test with representative data, wherever the platform offers one. Documentation access, and a named technical contact for questions that need a decision.
What we will not ask for
A named individual's login. If a requirement would need one, we will tell you the integration needs redesigning instead. Administrator rights where a scoped role will do. Production write access during build. Credentials sent by email, chat or ticket. Standing access after handover.
Specialists working inside your team
Where we supply engineers who work in your team rather than delivering a scoped build, those people work under your access policies and your onboarding, not ours. That model is described on how we work and our page for IT services companies.
Audit Trail Is More Than Platform Logging
Finance platforms log who changed what and when. That tells an auditor the integration made an entry. It does not tell them which transaction caused it.
Entries created by an integration join the journal entry population your auditor tests for fraud.
The PCAOB's 2025 staff guidance on journal entries states that management-override risk applies to entries processed through automated systems, not only manual ones, and that the population examined must be tested for completeness. So we add two things the platform cannot give you: a source reference on every entry leading back to the originating transaction, and a run log that records what each execution read, wrote and rejected, with counts and values on both sides. That log is the evidence for any control relying on the automation, retained on terms agreed with you rather than rotated away at a default interval.
Error Handling and Alerting
A finance automation should fail in a way that is loud, attributed and recoverable.
The last two are what most implementations miss. A run that never started produces no error log, so log-based alerting cannot see it. The schedule needs its own heartbeat. And a run processing ten times the usual volume is usually a bug upstream rather than a busy day; halting before writing is cheaper than reversing afterwards.
Change Control and the ITGC Question
If your organisation is in scope for SOX, the automation sits inside IT general controls. A reviewer will test it there, so it is built to be testable there.
How changes are made
Posting logic, matching rules, thresholds and mappings live in version control, not in a configuration screen somebody edits at month end. Every change has a ticket, a reviewer other than the author, and a release record produced by the process rather than written up afterwards. Where you have your own change process, we work inside it.
What the reviewer gets
A change log covering the life of the automation, attributable to a person. The permission specification for every service account. Evidence of segregation of duties, with the service account mapped against the same conflict matrix a person would be, documented before build rather than after a finding. Parallel run evidence from go-live, signed by the control owner.
Why this can reduce your testing
Worth noting in the other direction, because it rarely gets said: PCAOB AS 2201 treats automated controls as generally lower risk where IT general controls are effective, and permits a benchmarking approach for automated application controls in later years. A well-controlled automation can reduce annual testing effort rather than add to it.
Only if the control evidence exists, which is why we produce it during build.
API Versus RPA: the Decision Table
We state this plainly because it is often the reviewer's real question. The decision is made per step rather than per project, and documented in the interface assessment before build.
From a security standpoint the distinction matters beyond reliability. An API integration authenticates as a scoped service account with permissions you can enumerate. A screen automation authenticates as whatever the user interface requires, which is often a broader set of rights than the task needs. Where RPA is unavoidable we will say so, scope the account as tightly as the interface permits, and state the residual risk rather than describing it as equivalent.
What These Standards Apply To
Everything on this page applies to every finance automation we build. Each page below is written for a different reader.
Finance process automation services
The full scope: accounts payable, subledger-to-ledger flows, reconciliation, collections, close and master data, plus how an engagement is staged.
Send your finance team here →Sage Intacct integration services
Posting rules and grain, duplicate prevention using the platform's own replay protection, error routing, and what the Intacct audit trail does and does not give you.
Read the detail →Payment and bank reconciliation automation
The three-way match, why processor payouts never equal the day's transactions, and how the exception queue is designed to be audit evidence.
Read the detail →Review Questions We Are Usually Asked
What IT and security reviewers raise before approving a finance automation engagement.
A dedicated service account in each system in scope, created by you, with permissions scoped to the objects the integration reads and writes, and a non-production instance for build where the platform offers one. We do not ask for a named individual's login, administrator rights where a scoped role will do, or production write access during build. Access is removed at the end of the engagement unless a support arrangement says otherwise in writing.
In a managed secret store, yours where you have one, so the credential never leaves your control. Never in source control, configuration files, scripts, email, chat or a ticket. If your process requires a specific credential exchange method, we use it. If you require rotation on a schedule, the integration is built to handle rotation without an outage, which is a design decision rather than something retrofitted.
Three mechanisms. Every run produces a reconciliation: count and value read against count and value written, with any difference explained. The schedule has its own heartbeat monitor, so a run that never started raises an alert rather than producing no log at all. And a volume anomaly halts the run before it writes anything, because ten times the usual record count is almost always a bug upstream rather than a busy day.
It creates ITGC scope, which is not the same as a problem. The automation sits inside logical access, change management and operations, so it is built to be testable there, with versioned logic, peer-reviewed changes, a release record, a documented permission specification and segregation-of-duties mapping done before build. Worth knowing in the other direction: PCAOB AS 2201 treats automated controls as generally lower risk where IT general controls are effective, and permits a benchmarking approach in later years.
Only where a system exposes no interface, which in finance usually means a bank or government portal. It is a legitimate concern, and the honest answer is that a screen automation authenticates as whatever the user interface requires, which is often broader than the task needs. Where it is unavoidable we scope the account as tightly as the interface permits and state the residual risk rather than describing it as equivalent to an API integration.
We work inside your tenant wherever the platform allows it, so the data does not move. Where it must move, and document extraction is the usual case, only the fields needed for the purpose go, and retention is agreed in writing rather than left to a default. We are happy to complete your own security questionnaire and to work within data residency requirements; raise those at the first conversation rather than at contract stage.
Reviewing Us? Ask the Awkward Question First
If something here does not meet your standard, or your questionnaire covers ground this page does not, send it over. We would rather answer it now than discover a blocker after your finance team has committed to a timeline.