The Addepar integration with Sage Intacct handles portfolio reporting without issue, but Sage Intacct brokerage reconciliation breaks at a specific point in the workflow: your brokerage transactions transfer to Sage's backend successfully, then vanish before they reach the reconciliation module. You can't surface them, you can't match them, and you can't clear them against your books. The reconciliation layer was built for simple bank feeds, and brokerage accounts carry security identifiers, lot details, and asset class flags that the module was never designed to process.
TLDR:
- Sage Intacct cannot match brokerage accounts because its module only processes Plaid feeds
- Addepar data reaches Sage's backend but never surfaces in the reconciliation interface
- Manual workarounds cost family offices managing 200+ active entities roughly 20 man-hours per week on brokerage reconciliation
- Truewind pulls brokerage data from portfolio systems and matches it against Sage GL entries
- AI matching handles dividend reinvestments and trade variations that rules-based systems miss
The Technical Gap: Why Sage Intacct Cannot Match Brokerage Accounts
The limitation is architectural. Sage Intacct's reconciliation module is built around Plaid-compatible bank feeds, which handle standard checking and savings accounts without issue. Brokerage accounts are a different story.
While Sage Intacct bank reconciliation best practices can optimize standard account workflows, those same techniques do not translate to brokerage feeds that carry security-level detail.
When organizations pipe brokerage data into Sage via portfolio management systems like Addepar, the data lands on the backend server but never surfaces in the reconciliation module. You cannot interact with it or match it against your books. It sits there, because Sage's reconciliation layer is not built to process non-Plaid financial feeds.
For family offices managing hundreds of brokerage accounts, that limitation makes Sage's native reconciliation module functionally unusable for a core part of their portfolio.
What Happens When You Try to Feed Brokerage Data Into Sage Intacct
The failure happens at a specific point in the workflow. You connect Addepar, configure the data feed, and transaction data successfully transfers to Sage's server. That part works.
"If we wanted to take the Addepar data feeds and feed it into Sage today, what happens is the data shows up apparently on the server or the back end, but for whatever reason, it won't display in the reconciliation module in Sage. So you can't do a bank-to-book reconciliation in Sage for brokerage accounts."
The data exists. Sage just cannot surface it for matching. The reconciliation module never receives it, and no configuration change inside Sage fixes this.
Why Standard Bank Feeds Do Not Work for Investment Accounts
Standard bank feeds operate on a simple transaction model: an amount, a direction, and a date. Checking account activity maps cleanly to that schema. A payroll transfer out, a client payment in. The data is flat and predictable enough that automated matching works.
Brokerage accounts generate something structurally different. A single day of investment activity can include trades, dividend receipts, management fee deductions, realized gains from sales, and asset transfers between custodians. Each of those events carries fields with no equivalent in a bank feed: security identifiers, lot details, cost basis, asset class, and tax treatment flags. There is no single debit or credit amount to anchor the record.
Sage's reconciliation module was built to parse one type of data. Brokerage accounts produce another. That mismatch is not a configuration issue you can work around inside Sage. The data types simply do not fit the schema the feed expects.
The Manual Workaround (And Why It Fails at Scale)
Most teams default to a combination of manual exports, pivot tables, and ad hoc journal entries to bridge the gap. A controller pulls a custodian statement, exports the Sage Intacct GL, and spends hours matching line by line. It works until it doesn't.
Manual reconciliation in family offices produces data inconsistencies and version control problems that compound across entities, turning a simple matching task into a multi-week close process.
The failure points multiply as portfolios grow. More accounts mean more exports. More asset classes mean more formatting inconsistencies. More transactions mean more opportunities for a missed entry or a stale price to slip through undetected until month-end close is already underway.
| Reconciliation Method | Data Processing | Time Cost per Week | Handling Complex Transactions |
|---|---|---|---|
| Manual Excel Matching | Export custodian statements, reformat in pivot tables, construct journal entries by hand, paste into Sage Intacct GL | 20+ hours for firms with 200+ active entities | Dividend reinvestments, lot-level trades, and fee offsets require manual review and formatting for each occurrence |
| Sage Intacct Native Reconciliation | Brokerage data reaches backend server but never surfaces in reconciliation module due to Plaid-only feed architecture | Not functional for brokerage accounts | Cannot process security identifiers, cost basis, or asset class flags that brokerage feeds contain |
| Addepar Integration Alone | Portfolio reporting data flows to Sage for positions and valuations, but transaction-level data cannot be matched in reconciliation interface | Requires manual journal entry construction to bridge the gap | Data exists on server but reconciliation module cannot access it for bank-to-book matching |
| AI Reconciliation Layer (Truewind) | Ingests custodian feeds, matches brokerage transactions against GL entries using LLM-based matching, routes exceptions to review queue | Eliminates the 20-hour manual reconciliation cycle | Handles coding variations across custodians, dividend reinvestments, and multi-leg trades without rule configuration |
How Family Offices Are Actually Managing Brokerage Reconciliation Today
Managing brokerage reconciliation in Sage Intacct today often means bridging two systems that were never designed to speak to each other. A firm running 210+ active entities across 350+ bank and brokerage accounts can expect roughly 20 man-hours per week just on manual reconciliation for the most active accounts.
The workflow typically looks like this:
- Addepar aggregates portfolio data on one side, Sage holds the books on the other, and a staff member sits between them exporting, reformatting, and manually constructing journal entries.
- When brokerage accounts also process AP payments, entries already sitting in Sage's AP module can overlap with brokerage statement transactions, with no systematic check before they reach the GL.
The Addepar Integration Problem: Data Exists But Cannot Be Used
The Addepar-to-Sage integration handles portfolio reporting well: positions, valuations, and performance data flow into your ERP for visibility. Bank-to-book reconciliation is a different requirement entirely.
The reconciliation module needs individual transactions surfaced and matched against GL entries. That is not what the Addepar-to-Sage data path was built for, and no configuration change inside either system closes that shortfall.
Firms hit this wall mid-implementation. Reports populate. Data flows. But when a controller opens the reconciliation module to clear brokerage transactions against the books, there is nothing to work with.
Bank-to-Book Reconciliation: What It Means for Brokerage Accounts
Bank-to-book reconciliation matches what your brokerage custodian reports against what lives in your general ledger. For operating accounts, this is straightforward. For brokerage accounts, it breaks down fast.
Custodian statements carry positions, unrealized gains, accrued interest, dividend reinvestments, and fee offsets. None of these map cleanly to a standard bank feed. Sage Intacct expects debits and credits. Your custodian delivers a portfolio snapshot.
The disconnect between those two formats is where reconciliation falls apart, and where finance teams lose hours every close cycle trying to force a match that the system was never designed to produce automatically.
Where the Reconciliation Actually Needs to Happen
The reconciliation layer has to live outside the GL. Brokerage data requires a separate ingestion layer that pulls custodian feeds, matches bank-side activity against book-side positions, routes exceptions to reviewers, and then pushes only clean, approved entries back into Sage.
Sage remains your system of record. It just no longer carries the burden of the matching logic itself.
This separation keeps your GL clean without forcing your team to manually bridge the structural divide between how brokerages report transactions and how Sage expects to receive them.
Building a Reconciliation Layer That Syncs Back to Sage Intacct
The most durable fix isn't a workaround inside Sage Intacct. It's a dedicated reconciliation layer that sits between your custodian feeds and your GL, resolves the structural mismatches described above, and writes clean, validated journal entries back into Intacct automatically.
That layer needs to handle a few things your current workflow likely doesn't:
- Position-level matching across custodian lots, beyond cash totals
- Automated detection of accrued interest and trades before they hit your GL
- Journal entry creation that maps directly to your Intacct chart of accounts and dimension structure
When those pieces are in place, your team stops manually chasing trade date versus settlement date gaps and starts reviewing exceptions only.
How AI Reconciliation Works for Brokerage Accounts
Truewind treats Sage Intacct's GL entries as the book side and your Addepar or custodian statement data as the bank side. The system reads what's already posted in Sage, ingests brokerage transaction data through a separate feed, and runs AI matching across both sets simultaneously.
Where a rules-based system would fail on a dividend reinvestment coded differently across two custodians, LLM-based matching handles the variation. Trades, fees, dividends, and transfers each get matched to corresponding GL entries. Items that don't resolve cleanly route to a reviewer queue instead of silently hitting your books.
Once approved, matched entries sync back into Sage with full dimensional mapping intact, down to department, class, and any custom dimensions in your Intacct instance. Your GL stays clean. Your team reviews exceptions only. For family offices managing 200+ active entities across 350+ bank and brokerage accounts, that shift covers roughly 20 hours of manual reconciliation work per week on the most active accounts.
Final Thoughts on Managing Investment Reconciliation in Sage
Your GL can stay in Sage Intacct without forcing your team to manually bridge the distance between custodian statements and book entries every month. Brokerage bank to book reconciliation works when you build a separate matching layer that handles the structural differences before anything hits your GL. The system reads what's posted in Sage, ingests custodian data through a clean feed, and routes only unresolved items to your reviewers. If you're spending 20+ hours a week on manual brokerage reconciliation, see a demo of how AI matching cuts that time down.
FAQ
Can I use Sage Intacct for brokerage account reconciliation without third-party tools?
No. Sage Intacct's reconciliation module cannot process brokerage data feeds, even when custodian data reaches the server through systems like Addepar. The data lands on the backend but never surfaces in the reconciliation interface where you need it for bank-to-book matching.
Sage Intacct brokerage reconciliation vs manual Excel matching?
Manual Excel matching works for small portfolios but fails at scale. Family offices managing 200+ entities typically lose 20 hours per week exporting custodian statements, reformatting data, and constructing journal entries by hand. An automated reconciliation layer that syncs back to Intacct eliminates the export loop entirely.
Why won't my Addepar feed show up in Sage Intacct's reconciliation module?
The reconciliation module was built for Plaid-compatible bank feeds with simple debit/credit structures. Brokerage transactions carry security identifiers, lot details, cost basis, and tax treatment flags that don't fit that schema. Your data exists in Sage but cannot be matched against GL entries through the native reconciliation interface.
How do I match investment accounts in Sage Intacct when the data won't display?
Build a separate reconciliation layer outside your GL that ingests custodian feeds, matches brokerage transactions against book-side positions using AI, routes exceptions to reviewers, and writes validated journal entries back into Sage Intacct with full dimensional mapping intact.
What's the fastest way to stop manual brokerage reconciliation in Sage?
Connect your custodian data to a system that handles position-level matching and generates Sage-ready journal entries automatically. Your team reviews exceptions only while matched transactions sync directly to your GL with department, class, and custom dimensions preserved.
Turn this into a close-ready workpaper
Start with sample files or upload your own statements to see how Truewind prepares review-ready workpapers and journal entries.