Merging Multiple Portfolio Files Into One

tsneed290 · April 15, 2026, 8:43pm

When I first started using this app years ago I kept different portfolio files for things like my partner and I’s 401ks and our “fun” portfolio accounts, etc. What I’m now lacking is the full picture. These days I am good enough with the filters that I could now see that keeping everything in one portfolio file makes more sense.

What I’m lacking is understanding the mechanics of merging these portfolio files into one new one. Is there some way to merge the portfolios through some export/import trick? Will I need to recreate all of the accounts and securities and then just manually export transactions as a CSV and import into the new portfolio file?

Thanks for any help!

Rafa · April 16, 2026, 5:36pm

I’ve opened a PR that adds support for merging multiple Portfolio Performance files into a new combined file.

The idea is simple: select multiple files, merge them into one new file, and keep existing references consistent where possible.
Matching securities are reused conservatively to avoid incorrect merges, while ambiguous entries may still remain duplicated.

Important: this currently creates a new merged file and does not merge data into the currently opened file in place. Dashboards are intentionally ignored for now, and taxonomies are not merged yet.

github.com/portfolio-performance/portfolio

Open Combine multiple Portfolio Performance files into a newly merged… (#5635)

master ← Morpheus1w3:PortfolioMerge-V2

opened 11:47AM - 20 Apr 26 UTC

Morpheus1w3

+1801 -1

## Summary Adds support for merging multiple Portfolio Performance files into a… new combined file. ## Scope - loads multiple selected files - merges them into a new client instance - reuses matching securities where possible based on a conservative identifier heuristic - remaps security references in transactions, watchlists, and investment plans - regenerates UUIDs for imported accounts, portfolios, and transactions to avoid conflicts ## Limitations - dashboards are intentionally ignored - taxonomies are currently not merged - ambiguous securities are not force-merged and may still be duplicated ## Notes for review This feature is intentionally implemented as a "create new merged file" workflow. It does not merge additional data into the currently opened file in place. ## Design decisions - The merge creates a new combined client from multiple selected files. - It does not merge into the currently opened file in place. - Security matching is intentionally conservative to avoid incorrect merges. - Ambiguous matches are left duplicated instead of being force-merged. ## Intentionally out of scope - Dashboards are ignored. - Taxonomies are currently not merged. - Existing workspace/UI state is not preserved as part of the merge result. ## Processing flow 1. The user selects two or more files. 2. The first selected file is loaded as the base target client. 3. Each additional file is loaded as a source client. 4. Securities from the source are matched conservatively against the target. 5. Security references in transactions, watchlists, and investment plans are remapped. 6. UUIDs for imported accounts, portfolios, and transactions are regenerated. 7. The prepared source objects are appended to the target client. 8. The merged result is opened as a new portfolio file. 9. A summary dialog is shown after completion. ## UUID handling UUIDs for imported accounts, portfolios, and transactions are regenerated after remapping to avoid collisions when combining data from multiple files. ## Security matching Securities are only reused when the identifier match is unique on both sides. Current heuristic prefers stronger identifiers first (e.g. ISIN/WKN/currency combinations) and only falls back to weaker matches if they remain unambiguous. Ambiguous entries are intentionally kept separate. ## Security matching heuristic The merge logic uses a conservative, priority-based heuristic to decide whether two securities should be reused instead of duplicated. A match is only accepted if the corresponding key is **unique on both sides** (source and target). If a key is missing or ambiguous, the next weaker level may be evaluated. If no unique match can be found, the security is imported as a new entry. | Priority | SecurityMatchLevel | Required fields | Meaning | Strength | Typical use case | Risk of false match | Notes | |----------|----------------------|----------------------------|---------|----------|------------------|---------------------|-------| | 1 | `ISIN_WKN_CURRENCY` | ISIN + WKN + Currency | Strongest identifier combination | Very high | Fully maintained security master data | Very low | Preferred match level whenever available | | 2 | `ISIN_CURRENCY` | ISIN + Currency | Match by ISIN with currency as additional safeguard | High | WKN missing, but ISIN is available | Low | Useful when WKN is not maintained consistently | | 3 | `WKN_CURRENCY` | WKN + Currency | Match by WKN with currency as additional safeguard | Medium to high | ISIN missing, but WKN and currency are available | Medium | More practical for older or locally maintained data | | 4 | `ISIN_WKN` | ISIN + WKN | Match by two identifiers without currency | High | Currency missing, but both identifiers are present | Low to medium | Still strong if both identifiers are available | | 5 | `ISIN_ONLY` | ISIN | Match only by ISIN | Medium | Only ISIN is available | Medium | Accepted only if unique on both sides | | Fallback | `WKN_ONLY` | WKN | Match only by WKN | Low | Only WKN is available | Higher | Treated as a separate fallback, not as a normal primary key level | ## Matching rules - Matching is evaluated from **highest priority to lowest priority**. - A match is only accepted if the key occurs **exactly once in the source** and **exactly once in the target**. - Ambiguous entries are **not force-merged**. - If no unique match is found, the security is imported as a new security. - `WKN_ONLY` is treated as a dedicated fallback because it is weaker and more error-prone than the other key combinations. ## Design rationale This heuristic intentionally prioritizes **safety over aggressive deduplication**. That means: - correct merges are preferred over broad merges - ambiguous securities may remain duplicated - incomplete real-world data can still be handled through weaker fallback levels - the logic remains traceable and reviewable <img width="609" height="323" alt="Popup" src="https://github.com/user-attachments/assets/5f360b5d-d31f-44f6-92aa-13ccc21bebac" /> <img width="414" height="338" alt="Stats" src="https://github.com/user-attachments/assets/77a6f50b-9289-40c2-b6d2-683d575182a1" />

tsneed290 · April 22, 2026, 6:49pm

This is really cool that you had a PR already for it. If I find some time maybe I’ll try to build the repo and try out your branch. I ended up going the manual route.

Here’s what I did in case anyone ever runs into a similar issue.

I had 4 *.portfolio files. I ended up picking the most complex one and merged the 3 other ones into that one.

I followed this post to migrate the securities into the target portfolio by doing the drag-and-drop trick. This kept all of the history and worked great.
I manually created the Deposit Accounts and Securities Accounts in the target portfolio. Making sure to keep the account names and reference accounts matching exactly.
I exported via File > Export > CSV Files and exported both Account Transactions and Securities Accounts Transactions. Hint: you can double-click Account Transactions and Securities Accounts Transactions parent tree item and it’ll export everything to a folder.
From the Securities Account tab, I right-clicked each securities account and clicked "Import CSV” and selected the corresponding transaction file from step 3. Doing the import this way seemed to be the easiest, with the mappings coming up correctly.
From the Deposit Account tab, I right-clicked each account and clicked “Import CSV” and selected the corresponding transaction file from step 3. When you review the transactions you’ll see duplicates that the import tool already caught so when you hit Finish you won’t see duplicate transactions.

I had tried importing via other ways such as File > Import but didn’t really have good success there. Also importing security transactions first seemed to make the process go better. This at least got me to a point where I could leverage Account Groups correctly and rebuild my performance dashboard pages.