Sage Intacct is the accounting system of choice for a large share of mid-to-upper mid-market professional services firms precisely because of its multi-entity architecture, project accounting module, and revenue recognition depth. When a firm runs both an enterprise PSA and Sage Intacct, the integration question is not about moving data from one system to another — it is about establishing which system owns which layer of financial truth. Get that boundary wrong and you end up with two parallel financial records that never quite agree. Get it right and the PSA and Intacct operate as a unified financial infrastructure, each doing what it is architecturally suited for.
The Subledger Model: Why It Changes How You Think About the Integration
The most important concept in a PSA-Intacct integration is the subledger. In accounting terms, a subledger holds the detailed records that summarize up to the general ledger. AR subledger details every invoice and payment. AP subledger details every vendor bill. The GL holds the summary balances. In the context of PSA-Intacct integration, the PSA operates as the project-level subledger: it holds every time entry, expense, billing rule, rate card override, WIP balance, and project margin calculation. Intacct holds the summary entries that flow from that detail — the invoice in the AR ledger, the cost allocation in the GL, the vendor payment in AP.
This architecture has a significant practical implication: project managers, billing coordinators, and resource managers work entirely in the PSA. They never need access to Intacct to do their jobs. Intacct remains a controlled financial environment for the finance team, receiving clean, already-reconciled summary data from the PSA rather than raw project transactions that finance would need to sort and validate. The complexity of multi-currency billing, inter-company allocations, and project-level margin tracking stays in the PSA, which is built for it. Intacct sees the result, not the working.
What the Connector Actually Sends — and What It Keeps
A well-architected PSA-Intacct integration sends three categories of transaction: accounts receivable entries (invoices and credit notes), accounts payable entries (expense reimbursements and vendor bills processed through the PSA), and general ledger entries (WIP adjustments, cost allocations, period-end accruals). Each transaction is sent exactly once, carrying a cross-reference number that links the Intacct entry back to the originating record in the PSA. That cross-reference is what makes reconciliation tractable — finance can move from an Intacct GL entry to the PSA project record behind it without rebuilding the audit trail from scratch.
What the connector does not send is the project-level detail. Individual time entries, expense line items, billing rule configurations, and rate card structures stay in the PSA. Intacct receives summary-level AR entries — the invoice total, the client, the posting date — not a line-by-line breakdown of every hour billed at every rate. This keeps Intacct clean and manageable for the finance team while preserving the full operational detail in the system built to handle it.
Example: A 270-person management consultancy bills a client $142,000 for a completed project phase. The invoice is composed of 847 individual time entries across 12 consultants, three task types, and two billing rate tiers. The PSA sends a single AR entry to Intacct for $142,000, associated with the correct Intacct customer record and GL account. The $142,000 is correct because the PSA applied every billing rule accurately before it left. Finance sees one clean entry in Intacct. The 847 time entries are available in the PSA for any project-level audit, dispute resolution, or utilization analysis.
Accounting Period Control Across Both Systems
One of the more operationally significant capabilities in a mature PSA-Intacct integration is accounting period management. The PSA needs to control when transactions are eligible to be sent to Intacct — locking periods so that time entries, expenses, and billing adjustments cannot be backdated into a period that finance has already closed in Intacct. Without this control, a project manager who edits a time entry from last month creates a discrepancy between the PSA and the already-closed Intacct period, requiring a manual journal entry to correct.
Period control in the PSA operates independently from Intacct’s own period locking — the PSA enforces its own close at the project accounting level, preventing changes to transactions that have already been sent to Intacct. This gives finance a consistent, auditable boundary between what has been transmitted and what is still open for correction. For firms with complex month-end processes involving revenue recognition entries, WIP adjustments, and inter-company allocations, this boundary is what makes the close process repeatable rather than a manual coordination exercise between the PSA administrator and the Intacct administrator each month.
Multi-Currency and Inter-Company Transactions
Sage Intacct is well-suited to multi-entity accounting, but inter-company transactions and multi-currency billing add complexity that is better handled in the PSA before the data reaches Intacct. When a consultant in a UK entity delivers work on a project owned by a US entity, the PSA records the cost in GBP at the UK entity’s cost rates, calculates the inter-company charge at the agreed transfer price, and presents the transaction to Intacct already resolved: the UK entity has a receivable from the US entity, the US entity has a payable to the UK entity, and the billing to the end client reflects the correct USD rate. Intacct receives two clean entries, one per entity, rather than a raw inter-company transaction it needs to decompose.
The same logic applies to multi-currency billing for individual engagements. Exchange rate conversions, realized and unrealized FX gains and losses, and the separation of billing currency from reporting currency are all handled in the PSA before the GL entry is created. Intacct sees the correct functional currency amount for each entity without needing a separate FX revaluation run on project transactions that arrived in the wrong currency.
Access Control: Keeping Intacct Closed Without Slowing the Business Down
A common source of friction in firms that run both a PSA and an accounting system is access management: project managers need to see financial data to do their jobs, but giving them Intacct access creates security and audit risk. The subledger model resolves this cleanly. Because the PSA holds all project-level financial detail, project managers can access margin data, WIP balances, billing summaries, and budget versus actuals entirely within the PSA. They never need Intacct access, and finance retains full control over the GL environment. Role-based permissions in the PSA govern what each user can see and do at the project, cost center, and engagement level — independently from Intacct’s own permission model.
Reconciling the Two Systems Without Starting From Scratch
Reconciliation between the PSA and Intacct is the activity that breaks down most often in integrations that were not designed for it from the start. When every transaction sent from the PSA carries a cross-reference number that maps back to the originating PSA record, the reconciliation process becomes a lookup rather than a reconstruction. Finance compares the Intacct GL balance for a period against the PSA’s pre-built reconciliation report for the same period, identifies any discrepancies by cross-reference number, and traces them to the specific transaction in the PSA that generated them.
- Verify that the integration sends transactions exactly once with a cross-reference number. Duplicate transmission is the most common source of AR discrepancies in PSA-Intacct integrations and is a sign of a connector that lacks idempotency controls.
- Confirm that accounting period locking in the PSA prevents retroactive changes to transmitted periods. Ask the vendor to show what happens when a project manager edits a time entry in a closed period — the system should prevent or quarantine the change, not silently allow it.
- Test the inter-company transaction flow with a real example from your entity structure before go-live. This is the scenario most likely to surface account mapping gaps that become month-end problems after the integration is live.
