Integrations
We work with your stack. We do not ask you to replace it.
Accruna reads financial activity from the systems that already hold it — your ledger, banks, cards, payment processors and payroll provider — and writes back only what you have approved. Connections are read-only unless write access is explicitly required and agreed.
Connection principles
- Read-only by default. Write access is requested per system, justified and logged.
- Nothing ripped out. Your ledger stays yours; Accruna operates on it.
- Credentials encrypted. Stored encrypted, never logged, rotatable on request.
- Every sync observable. Each run records what it read, matched and rejected.
Directory
What we connect to, by category.
Categories are listed with the accounting consequence of each connection — what it produces, not just that it exists.
Accounting systems
Your chart of accounts, transactions and statements live here. Accruna maps to your ledger rather than creating a parallel one.
Access: read and write where required to post approved entries. Account mapping is versioned and reviewed with you at onboarding.
Banks and treasury
Statement lines, balances and fee detail. Bank feeds are the primary source for reconciliation, so coverage matters more here than anywhere else.
Access: read-only. Payments are initiated only through a separately authorised rail, never directly from a feed connection.
Cards and spend management
Card transactions, merchant descriptors, receipts and policy metadata — the richest source for expense automation.
Access: read-only for transactions and receipts; approval routing is handled inside Accruna rather than pushed back to the card provider.
Payments and revenue platforms
Payouts, refunds, chargebacks, fees and subscriptions. The detail behind the net figure is what makes gross margin calculable.
Access: read-only. Transaction-level reports preferred over payout summaries — the difference is the whole point.
Payroll and contractors
Gross-to-net payroll, employer taxes, benefits and contractor payments, tied back to the ledger each period.
Access: read-only. Payroll is never initiated by Accruna — we reconcile what your provider has already run.
Billing, AP and tax
Supplier invoices, purchase orders, sales tax determination and e-invoicing where your jurisdictions require it.
Access: read and write for invoice status and coding. Tax determination is consumed, not replaced — filing remains a separate engagement.
Connection mechanics
What actually happens when you connect a system.
Integrations fail quietly more often than they fail loudly. These are the controls that stop that happening.
Authenticate
OAuth where available, scoped API tokens where not. Credentials encrypted and never written to logs.
Map fields
Every source field is mapped to a destination field, and you review the mapping before it runs.
Backfill and verify
Historical data loads into a staging check first. Totals are reconciled against the source before go-live.
Sync and monitor
Scheduled syncs run with a health check. Failures alert us, and the ledger is never partially posted.
Controls that matter more than the connection itself
- Idempotency
- Re-running a sync never double-posts. Each source record carries a stable identifier, so a repeated import is a no-op rather than a duplicate.
- Rejected rows
- Anything that cannot be mapped is rejected with the reason recorded, and it stays visible until resolved. Silent dropping is not permitted.
- Sync health
- Each connection reports last successful sync, record counts and error rate. A stale connection is flagged rather than assumed working.
- Cut-off discipline
- Records dated after your period cut-off are held for the next period rather than posted into a closing one.
- Credential rotation
- Tokens are rotatable on request and are revoked immediately when a connection is retired.
- Reversibility
- If a connection produced incorrect results, the affected entries are identified by sync batch and reversed together.
| System | Last sync | Records | Health |
|---|---|---|---|
| QBQuickBooks | 28 Sep, 14:06 | 1,248 | Healthy |
| MCMercury | 28 Sep, 14:02 | 412 | Healthy |
| STStripe | 28 Sep, 14:01 | 3,918 | Healthy |
| RMRamp | 28 Sep, 13:58 | 876 | Healthy |
| GUGusto | 28 Sep, 09:04 | 96 | Healthy |
| PLPlaid | 28 Sep, 13:55 | 214 | Healthy |
When there is no native connection
Most systems have a route in, even without an integration page.
In practice, unfamiliar systems are rarely a blocker. There are four fallback routes, and we will tell you which one applies before you commit.
Route 1
API
If the system exposes a documented API and you can issue a token, we will build a mapping against it. This is the preferred route and usually the most stable.
Route 2
Scheduled export
A recurring CSV or spreadsheet export, collected on a schedule. Field mapping is reviewed once and versioned, so later changes are visible.
Route 3
SFTP drop
For systems that can push a file but not respond to a request. Files are ingested, validated and rejected with a reason if a field is missing.
Route 4
Manual entry, bounded
For genuinely low-volume sources, a structured intake form with validation. We will say plainly when this is the right answer rather than over-engineering it.
What we need to assess a new connection
Send us these four things and we can usually tell you within a working day whether a connection is straightforward, custom work, or not worth building.
- The system name and what it holds — transactions, balances, invoices, payroll, something else
- Whether it has an API and whether you can issue credentials, or whether your plan restricts it
- A sample export if one exists — one month is plenty to judge mapping complexity
- The volume — records per month, and how many entities or currencies it covers
| Source field | Destination | Transform |
|---|---|---|
| txn_date | Journal date | Direct |
| merchant_descriptor | Supplier | Normalise |
| amount_gross | Debit / credit | Sign by type |
| category_hint | Account | Rule + precedent |
| tax_code | Tax treatment | Lookup table |
| cost_centre | Class / dimension | Unmapped |
Unmapped fields block go-live rather than defaulting to a guess. Here, cost_centre needs a decision before the connection is enabled.
Data handling
Where your data goes, and where it does not.
Straight answers, because "we take security seriously" is not an answer.
In transit and at rest
- All connections use TLS; no unencrypted endpoints are permitted
- Ledger data, attachments and credentials are encrypted at rest
- API tokens are stored encrypted and are not written to application logs
- Access to production data is restricted and logged, with no standing access
What we never do
- Sell, share or repurpose your financial data
- Train third-party models on your ledger data
- Hold write access to a payment rail unless you have explicitly approved it
- Retain your data after an engagement ends, beyond the agreed retention window
- Connect a system you have not authorised, including ones discovered via an aggregator
Default access
Read-only
Write access is requested per system with a documented reason.
Payments
Never automatic
Money movement requires your authorisation, every time.
Sync visibility
Every run
Records read, matched and rejected are recorded and reviewable.
On exit
Full export
History exported, credentials revoked, retention agreed in writing.
Integration questions
Questions we get about connecting systems.
Including the ones where the answer is less convenient.
No. Accruna operates on the ledger you already use. Migrating ledgers mid-year introduces comparability problems, re-mapping risk and a period where nobody fully trusts the numbers.
There are cases where migration genuinely helps — an unsupported system, a structure that cannot handle multi-entity — but we will present that as a separate decision with its costs, not bundle it into onboarding.
Bank feeds, without question. Reconciliation is the foundation everything else rests on, and missing bank coverage means a manual step that never goes away.
After that, it depends on where your volume sits. Card-heavy businesses should prioritise the card provider; ecommerce businesses should prioritise transaction-level processor data rather than payout summaries.
We will try the aggregator route first, which covers most institutions. If that fails, we fall back to a scheduled statement export — PDF or CSV — which is less elegant but entirely workable.
For a small number of accounts, statement upload is genuinely fine. It becomes a problem when there are dozens of accounts across multiple entities, at which point we will say so.
Only where it is needed and only with approval. Typically that means posting coded transactions and approved journal entries into your ledger, and updating invoice status in a billing or AP system.
Everything else is read-only. Agent credentials are scoped to a single task rather than granted broad account access, so a coding agent cannot initiate a payment even if it wanted to.
All credentials are revoked, typically within a few business days of the final period being signed off. Your data remains in your systems throughout — we were operating on your ledger, not holding a copy of it.
Any Accruna-side working data is exported to you on request and then deleted according to the retention window agreed in the engagement letter. We will confirm both in writing rather than leaving it to assumption.
Yes, and we would rather you did where it makes sense. Connections can be scoped to specific accounts, entities or date ranges, and access is role-based on our side as well.
The one practical caveat: a partial view makes reconciliation harder, and we will flag any account we are asked to exclude so the effect on completeness is on the record rather than discovered later.
Tell us what you run. We will tell you what connects.
Bring your stack list to a demo — including the awkward systems nobody has heard of — and we will be specific about what is straightforward and what is not.