DEV Community: Steffan Kharmaaiarvi

How to Combine Portfolios From Multiple Brokers Without Connecting Your Accounts

Steffan Kharmaaiarvi — Fri, 04 Sep 2026 16:50:54 +0000

How to Combine Portfolios From Multiple Brokers Without Connecting Your Accounts

A practical way to build one investment history from separate broker statements—without pretending that a combined balance is enough.

For a while, I thought combining brokerage accounts was just an addition problem.

Open each app. Copy the current value. Convert everything into one currency. Add the numbers together.

That gives you a total. It does not give you a portfolio.

My own investments ended up spread across more than one account for fairly ordinary reasons. One account held older positions. Another became the place where I made new purchases. Each broker could tell me exactly what was held on its own platform, but neither knew anything about the other.

The missing answers were not exotic:

How much had I contributed across all accounts?
How much came from market movement rather than new money?
What was my combined cost basis?
How much income had I received, and how much tax had been withheld?
Was I looking at one portfolio or several unrelated dashboards?

This is where portfolio consolidation becomes harder than it first appears. The problem is not collecting three balances. The problem is reconstructing one history from systems that were never designed to talk to each other.

A portfolio is a ledger, not a balance

Suppose three accounts are worth $60,900 in total today. That number alone cannot tell you whether the investments performed well.

An illustrative history might look like this:

Component	Amount
Net contributions	$50,500
Market movement	$8,700
Dividends and interest	$2,000
Broker fees	−$180
Tax withheld	−$120
Portfolio value	$60,900

Someone else could have the same $60,900 balance after contributing $70,000. The current value is identical; the outcome is not.

Transfers make the picture even easier to distort. If I move $20,000 of securities from Broker A to Broker B, Broker A records assets leaving and Broker B records assets arriving. At the account level, those are real events. At the combined-portfolio level, I have contributed nothing new. Treating the receiving side as a fresh investment would inflate my lifetime contributions by $20,000.

The same problem appears with dividends, commissions, withholding, currency conversion and partial sales. A useful combined portfolio must preserve the events that produced the balance, not only the balance itself.

Four ways to put the accounts together

There is no universally best method. The right one depends on how many accounts you have, how often you trade, how much history you need and what kind of access you are comfortable granting.

1. Let one broker aggregate the others

Some brokers provide their own aggregation tools. This can be convenient because the analysis lives in an institution you already use.

The obvious limitation is coverage. The broker must support the other institution or account type, and the resulting view may be designed around current allocation rather than the complete transaction history you want to preserve. Employer share plans, older regional brokers and manually held investments are often the accounts that make consolidation necessary in the first place.

2. Use a tracker with live account connections

Connected trackers offer the least manual work. Once authorized, they can refresh holdings and transactions without another export.

It is important not to collapse every connection into “giving an app your brokerage password.” A modern OAuth flow redirects you to the financial institution, where you authenticate and authorize access. The third-party application receives permissioned access rather than your password. Plaid’s OAuth documentation describes exactly this model.

That is a meaningful security improvement over credential sharing. It does not remove every trade-off.

A connected service still needs continuing permission to retrieve financial data. Its usefulness depends on support for your institution, the fields supplied by that institution and the depth of history available through the feed. For example, Plaid Investments documents up to 24 months of investment transactions, while its standard account endpoint uses cached balances that typically update about once a day when the connection is healthy. Other providers have different limits; the point is that “connected” does not automatically mean complete or real-time.

For an active investor who wants automatic daily updates, this can still be the right compromise. For somebody who checks a long-term portfolio once a month, permanent access may solve a problem they do not actually have.

3. Maintain a spreadsheet

A spreadsheet is transparent, flexible and independent of any provider. For a small portfolio, it may be all you need.

The workload grows with every exception. You have to standardize tickers, preserve dates, account for commissions, convert currencies, distinguish dividends from deposits, match transfers and prevent the same transaction from being pasted twice. Then you have to maintain the formulas.

The spreadsheet does not usually fail in a dramatic way. It becomes less trustworthy gradually. One missing dividend, one overwritten formula or one transfer recorded as a contribution can produce a plausible result that is still wrong.

4. Import statements periodically

The fourth option is to treat each broker statement as a source document and build the combined ledger from those documents.

This is less automatic than a live connection, but it is not an improvised workaround. Broker reports can contain a surprisingly complete record. Interactive Brokers says its Activity Statements include positions, cash balances, fees, corporate actions, interest, dividends and trades. Its reporting tools also allow investors to create configurable CSV, XML and text exports through Flex Queries. IBKR documents the available reporting fields here.

DEGIRO similarly provides separate account, transaction and portfolio reports, with exports available in Excel, PDF and CSV formats. Its reporting documentation makes an important distinction: a portfolio overview is a snapshot of open positions, while account and transaction statements contain the activity behind those positions.

That distinction matters. A holdings screenshot can tell a tracker what you own today. It usually cannot reconstruct when you bought it, what you paid, what income it produced or how much of the current value came from your own contributions.

What the combined record actually needs

If I were evaluating any multi-broker tracker, I would look for more than a clean dashboard. I would want to know whether it preserves the following:

The source account. Every transaction should retain its origin. Combining accounts should not erase the ability to trace a number back to a broker statement.

Stable instrument identification. A ticker alone is not always enough. The same security can trade in different currencies or on different exchanges, and the same short ticker can refer to different instruments. ISINs and market identifiers help disambiguate them.

Dated external cash flows. Contributions and withdrawals need dates and amounts. Without them, money-weighted return is guesswork.

Internal transfers. Moving cash or securities between my own accounts should not become a new contribution to the combined portfolio.

Income and costs. Dividends, interest, commissions and withholding should remain separate. Folding everything into an unexplained gain hides exactly the leakage many investors are trying to understand.

Historical currency conversion. A contribution made in euros should retain its value at the exchange rate on the transaction date. Re-converting the old contribution at today’s rate silently rewrites history.

Duplicate detection. Overlapping statements are normal. I may export January through August in September and January through September in October. A safe importer should recognize previously recorded transactions before it changes the portfolio.

A review step. PDF layouts vary, CSV columns differ and corporate actions can be ambiguous. Extraction should be treated as a draft to verify, not as unquestionable truth.

The reconciliation test

After consolidation, the portfolio should pass a basic accounting identity:

Opening value + net contributions + market movement + income − fees − tax withheld = ending value

For example:

$42,000 + $7,000 + $3,100 + $612 − $84 − $168 = $52,460

If the two sides do not match, something is missing, duplicated or classified incorrectly. That disagreement is useful information. A tracker that simply assigns every unexplained difference to “market return” will always balance, but it cannot tell you whether the result is correct.

Performance requires another distinction. The return percentages shown by three brokers cannot simply be averaged. Contributions occurred at different times and in different amounts. Time-weighted return attempts to remove the effect of external cash flows so the underlying portfolio can be compared across periods; money-weighted return reflects the investor’s actual timing and size of those flows. Even professional performance standards require explicit policies for external cash flows and generally use time-weighted returns for comparability. The CFA Institute’s overview of the GIPS standards explains why this treatment matters.

For a personal portfolio, both views are useful. They answer different questions:

What did the portfolio do? Time-weighted return.
What happened to my money? Money-weighted return, often calculated as XIRR.

Neither is trustworthy without a sufficiently complete ledger.

“No broker connection” does not mean “no privacy decision”

A statement-based workflow removes one kind of access: the tracker has no standing authorization to query the broker, and it cannot use a broker connection to place trades or move money.

But a statement is still a sensitive financial document. It may contain a name, address, account number, holdings and transaction history. Uploading it requires a different set of questions:

Is the original file stored, and for how long?
Is the document sent to another processor for extraction?
Which fields are retained after parsing?
Can I review the extracted data before saving it?
Can I delete the portfolio and account myself?
Does the provider have an independent security certification or penetration test?

The right comparison is not “connected equals dangerous, document equals safe.” The right comparison is the exact access, retention, processing and deletion model of each service.

OAuth can be a sensible choice when it is implemented well and the institution supports it. Statement import can be a sensible choice when you want broad compatibility and periodic control. Manual entry remains the lowest-data-sharing option, at the cost of the most work.

The approach I ended up building

I ran into this problem while trying to maintain one coherent history across accounts. I wanted the combined analysis, but I did not need another service continuously connected to my brokerage accounts. That is why I ended up building BorderFolio around a document-in workflow.

Each broker or account can remain a separate portfolio, while the combined view brings them together. BorderFolio accepts PDF and CSV statements, as well as screenshots or photos when no useful export exists. It extracts positions and transactions, shows the result for review and skips transactions it has already imported. It never asks for broker credentials.

There is a trade-off, and it should be stated plainly. Arbitrary statement layouts are extracted using the OpenAI API, so the contents of an uploaded document are sent to that processor. BorderFolio keeps the original file in private storage only so a failed import can be retried and deletes it automatically within seven days. The product is still young: it does not have SOC 2 or ISO 27001 certification or a third-party penetration test. Manual entry is available for anyone who does not want to upload a statement. The complete details are published on the security and data-handling page.

I do not think this approach replaces connected trackers. If you trade frequently and want intraday updates, a reliable API connection is probably more convenient. If you need jurisdiction-specific tax filing, a portfolio tracker is not a substitute for tax software or an accountant. And if you have one account with five holdings, a spreadsheet may remain perfectly adequate.

Statement import is most useful for the awkward middle: several brokers, long holding periods, regular contributions and enough history that starting from today would throw away the part you actually want to understand.

The dashboard is the last step

Combining portfolios is often presented as a visualization problem. Put every account on one screen, draw an allocation chart and show a total balance.

The dashboard is the easy part.

The real product is the ledger underneath it: where every position came from, when money entered, what moved internally, which income was paid, which costs were taken and whether the pieces add up.

The best multi-broker setup is not necessarily the one with the most automation. It is the one whose history you can explain.

If a statement-based approach fits the way you invest, you can try BorderFolio with one portfolio for free. If your broker’s format does not import correctly, that is exactly the kind of feedback I am looking for.

Sources and further reading

Sources and product details checked on 4 September 2026. This article is informational only and is not investment, tax or legal advice.

My broker said I'd made $18,000. The number was an aggregate over a query nobody could show me.

Steffan Kharmaaiarvi — Mon, 31 Aug 2026 16:00:00 +0000

The number sat on my broker's home screen, green, precise to two decimals. Roughly eighteen thousand dollars, earned from investing, over the whole period I'd been at it.

I looked at it for a long time and realised I didn't know what it included.

Dividends — reinvested ones, or only the ones that landed as cash? Before or after the tax withheld in a country I don't live in? Closed positions, or only open ones? Fees? Measured from my first-ever deposit, or from the day I opened this account and transferred everything across?

Each of those moves the number. Some move it by thousands.

That's a familiar shape if you write software: an aggregate whose query you can't see. I spent a while looking for the drill-down and eventually understood there wasn't one to find. The breakdown didn't exist. Nobody was keeping the events — not the broker, not my spreadsheet, not any of the tools I tried.

I'm a self-taught engineer, 24, and I've been contributing to a portfolio monthly for years with financial independence as the actual goal. The strategy is unfashionably boring — broad market exposure, automatic monthly transfer, reinvest, don't touch it — and it worked. The portfolio reached six figures through contributions and time, not through a trade that went right.

Then my income changed, my contributions got uneven, and the balance stopped functioning as feedback. It still went up. But "the balance went up" now had at least four meanings that demanded different responses from me:

I contributed a lot, the market was flat.
I contributed almost nothing, the market carried it.
I contributed steadily and both worked.
I contributed nothing, the market fell, and dividends plus a favourable exchange rate papered over it.

One number, four stories, no way to tell them apart. So I started reconstructing the events by hand, and found five bugs — not in any one product, but in the data model almost all of them share.

Bug 1: the balance is a materialized view with no source table

Every tool I used stored the same thing: a set of positions with prices. Current holdings, current value, correct to the cent.

That model throws away most of what happened. My portfolio didn't stay the same shape — I spent a few years pursuing dividend income toward a $500/month target, then came round to the view that during accumulation, income you immediately reinvest is mostly a taxable event with extra steps. What I converged on was simpler: a global accumulating fund as the core, short-term treasuries, gold.

Look at my holdings today and you'd conclude I'd always been a three-fund accumulator. That's false, and it means the actual history — including the parts I got wrong — isn't learnable from the data.

A holdings screen is a snapshot of the conclusion. I wanted the working:

positions  ← what every tracker stores
   ↑
   │  fold(events)
   │
events     ← what nobody stores
  deposit, buy, sell, dividend, fee,
  withholding, fx_conversion, residence_change

Positions are derivable from events. Events are not derivable from positions. Once you write it that way the direction of the arrow settles the design argument. Contributions in particular stop being a bookkeeping entry that makes the pie bigger and become a first-class record: dated, distinguished from reinvested income, with rhythm, streaks and gaps visible.

Bug 2: `return` is not one function, and two correct implementations disagree on the sign

This is the one that turned a preference into a real problem. I computed my return one way, then another way, and got a different answer — not slightly different, opposite sign.

Minimal reproduction:

Date	Event	Portfolio value
1 Jan	Deposit $1,000	$1,000
1 Jul	Holdings up 50%	$1,500
1 Jul	Deposit $9,000 — the plan is working	$10,500
31 Dec	Holdings fall 10%	$9,450

Time-weighted return — what funds and indices publish — deliberately cancels out the effect of deposit timing by chaining sub-period returns between cash flows:

def twr(sub_period_returns):
    """Geometric chain. Deposit timing has no effect by construction."""
    growth = 1.0
    for r in sub_period_returns:
        growth *= (1 + r)
    return growth - 1

twr([0.50, -0.10])   # 0.35  → +35%

Money-weighted return — XIRR — dates every cash flow and solves for the rate that discounts them to zero:

def xnpv(rate, flows):          # flows: [(date, amount)], deposits negative
    t0 = flows[0][0]
    return sum(a / (1 + rate) ** ((d - t0).days / 365.0) for d, a in flows)

def xirr(flows):                # bisection: no derivative, no divergence
    lo, hi = -0.9999, 10.0
    for _ in range(200):
        mid = (lo + hi) / 2
        if xnpv(mid, flows) > 0: lo = mid
        else:                    hi = mid
    return (lo + hi) / 2

xirr([(jan1, -1_000), (jul1, -9_000), (dec31, 9_450)])
# -0.0978 with ACT/365 to 31 Dec; -0.0973 measured over a full year → −9.7%

Both are correct. The strategy had a great year; the investor lost $550, because 90% of the money only showed up for the bad half.

A tracker that renders one of these and labels it "your return" is answering a question you may not have asked. I don't think that's dishonesty — it's compression. One percentage is a nicer product decision than two percentages and an explanation. But the compression is exactly where the information I wanted was going.

Once I saw it the whole vocabulary came apart. There are at least four distinct things called "return":

Unrealized gain — revaluation of what I still hold, against what I paid. Says nothing about anything sold, nothing about income.
Realized gain — what I locked in by closing positions. Real, spendable, usually taxable somewhere.
Personal return (XIRR) — the annualised rate my actual money earned, each deposit weighted by how long it was invested. The only common metric that admits a January deposit and a December deposit are not equal contributors to the year.
Portfolio return (TWR) — how the strategy performed with flows removed. The only one comparable to an index, because it's the only one not contaminated by how much money happened to be in at the time.

For an uneven contributor, the gap between the last two isn't noise, it's the finding. A wide divergence means the timing of my contributions, not my fund choices, dominated the year. That's actionable in a way neither number is alone.

Bug 3: rates applied at read time instead of event time

Classic temporal-data mistake, and it's everywhere in this domain.

If a tool converts a contribution I made three years ago at today's exchange rate, my savings history silently resizes itself every time the currency moves. I open the app in March and I contributed $47,000 lifetime; I open it in June and I contributed $44,100. I did not withdraw anything.

# wrong: history is recomputed against the present
total = sum(f.amount * fx_rate_now(f.currency) for f in flows)

# right: a flow is stamped at the rate on its own date; only
# what you hold today is valued at today's rate
total = sum(f.amount * f.fx_rate_at_trade_date for f in flows)

Same rule as storing a price with an order line instead of joining to the product table at render time. Sounds pedantic until you've watched your own record of what you contributed change while you weren't looking, and had to decide which version to believe.

Bug 4: tax is a function of three variables, and one of them is time

Here's the part I got most wrong at the start.

I assumed a fund is a fund: pick the index, find the cheapest vehicle tracking it, buy it. Ticker and expense ratio, done. Inside a single country that's correct advice. Across borders it isn't, because a foreign dividend can pass through two independent tax layers.

Step one, at source. The fund's country takes its cut before the money leaves. For a non-US investor in a US-domiciled fund the statutory US rate is 30%; a treaty commonly reduces that to 15%, but only where your broker holds valid documentation for you, and that paperwork expires.

Step two, at home. Your country of residence then taxes the same dividend under its own rules.

The steps are independent, which produces the result that surprises everybody: moving somewhere with no dividend tax does not make step one disappear.

Step one alone, on an illustrative portfolio throwing off $571/year in dividends from US-domiciled funds:

Tax residence	US treaty status	Withheld at source	Reaches you
United Arab Emirates	No US tax treaty	30% · $171	$400
Portugal	Treaty rate on portfolio dividends	15% · $86	$485
Germany	Treaty rate on portfolio dividends	15% · $86	$485

Same funds, same amounts, same dates. Different residence. Eighty-five dollars a year before anyone has picked a single stock, recurring annually.

So the withholding rate isn't a column on the instrument. It's rate(fund_domicile, tax_residence, as_of_date) — and as_of_date matters because people move. When residence changes the portfolio doesn't move; not one share changes hands. But the rate on every future dividend changes, and sometimes what you're permitted to buy changes too. The honest answer to "how much tax did this portfolio lose?" is the rate that applied at the time, changing partway through, applied to the dividends actually paid in each period.

There's an elegant wrinkle: an Irish-domiciled UCITS fund holding US stocks pays 15% at the fund level under the US–Ireland treaty, and Ireland charges nothing further on distributions to non-residents. So an investor in a country with no US treaty can end up at 15% instead of 30% on the same underlying index, purely because of where the fund is registered.

The obvious conclusion is that everyone outside the US should hold Irish UCITS. I believed that for about a week, then ran it per holding, and it fell apart:

switch A:  net  +$32/yr   worth doing
switch B:  net   −$7/yr   the fund barely pays dividends, so there was
                          almost no withholding to save — and the UCITS
                          alternative's higher expense ratio is charged
                          against the entire position, not just the income

Counting only tax saved makes every row look free. The tax saving scales with dividend yield; the expense-ratio penalty scales with your entire balance. Different denominators. Which wins depends on the fund, your portfolio size, your residence, and the fund's own costs — and it can flip as the position grows. Lower withholding doesn't mean better; it means one term in the equation improved.

Bug 5: the state transition nobody emits an event for

A non-US person's estate can be exposed to US estate tax on US-situs assets above $60,000 — a category that includes US-domiciled ETFs and individual US stocks — at rates reaching 40% on the excess. Not income tax. Estate tax. Whether it bites, and how hard, depends on treaty coverage, available deductions, how assets are held, and the circumstances of the estate. It's a line worth knowing you've crossed, not a bill anyone can compute for you.

A long-term index investor crosses it in an ordinary month of an ordinary year. No email, no warning, no change of state anywhere — because from the dashboard's point of view nothing happened. The threshold isn't in the model, so no event fires.

I'd crossed it long before I knew it existed.

The rule I ended up caring about most

When a metric can't be computed, say so. Never print a zero.

# a hole in the history and a genuine zero must not render identically
@dataclass
class Metric:
    value: Decimal | None
    confidence: Literal["exact", "approximate", "unavailable"]
    reason: str | None      # "no valuation recorded around 2024-03-11 cash flow"

TWR needs a portfolio valuation around every external cash flow. Where one is missing, the standard workaround is an approximation — and it should be labelled as an approximation, not blended into a headline figure. You cannot reconstruct a valuation nobody recorded. I tried.

What I built

BorderFolio — a contribution-first portfolio tracker for long-term international investors. Statements in (PDF, CSV, a screenshot of a broker app, or typed by hand), history out. No broker credentials and no permanent connection, because I didn't want to hold anyone's login, including my own.

It keeps contributions as a first-class record, splits the result into its actual components (contributions, market growth, income, fees and withholding, realized and unrealized), reports personal return and portfolio return side by side, keeps monthly snapshots so the past stays the past, and resolves withholding per instrument from fund domicile and configured residence — showing both sides of a structural switch, not just the flattering one.

What it can't do, out loud: it's statement-import based rather than live API, so you upload something once a month. Every calculation is only as good as the records imported, and a missing statement is a hole the tool shows rather than interpolates over. The portfolio-return number genuinely improves as monthly history accumulates, and I can't make that instant. The cross-border figures are informational estimates from published treaty rates and fund documents — not tax advice, and blind to your personal circumstances. Nothing in it, including my own portfolio's shape, is a recommendation.

The free tier is enough to see whether the idea holds up on your own numbers.

What I'd most like from this crowd is the thing this domain punishes hardest: a number that's confidently, plausibly, quietly incorrect. The interesting failures in a tool like this aren't crashes. If you find one, I want to know about it more than I want a signup — admin@borderfolio.app, or in the comments.

The full arithmetic behind all four return metrics, with worked examples, is in how to track portfolio performance. The two-step withholding model and how each rate is resolved is in the methodology.

BorderFolio provides informational portfolio analytics only. Nothing here is investment, financial, legal or tax advice, and no figure in this article is a recommendation to buy, sell or hold any security. Illustrative figures are exactly that. Tax rules change and depend on individual circumstances — verify anything that matters with a qualified adviser in your jurisdiction.

DEV Community: Steffan Kharmaaiarvi

How to Combine Portfolios From Multiple Brokers Without Connecting Your Accounts

How to Combine Portfolios From Multiple Brokers Without Connecting Your Accounts

A portfolio is a ledger, not a balance

Four ways to put the accounts together

1. Let one broker aggregate the others

2. Use a tracker with live account connections

3. Maintain a spreadsheet

4. Import statements periodically

What the combined record actually needs

The reconciliation test

“No broker connection” does not mean “no privacy decision”

The approach I ended up building

The dashboard is the last step

Sources and further reading

My broker said I'd made $18,000. The number was an aggregate over a query nobody could show me.

Bug 1: the balance is a materialized view with no source table

Bug 2: return is not one function, and two correct implementations disagree on the sign

Bug 3: rates applied at read time instead of event time

Bug 4: tax is a function of three variables, and one of them is time

Bug 5: the state transition nobody emits an event for

The rule I ended up caring about most

What I built

Bug 2: `return` is not one function, and two correct implementations disagree on the sign