mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-10 23:54:00 -05:00
[GH-ISSUE #522] [Bug] Exporting to csv doesn't account for split transactions #97608
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#97608
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rich-howell on GitHub (Jan 22, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/522
Discussed in https://github.com/actualbudget/actual/discussions/191
Originally posted by bpaulien August 19, 2022
I did an export to csv of one of my accounts (and later for all accounts) and looked for how splits were indicated, and see that there is absolutely nothing to indicate if a transaction was part of a split or not. Is this by design, or oversight?
my example:
I exported one account from Actual, and there was one split transaction on that account. I located it in the csv, and there doesn't appear to be anything to distinguish it from any other transactions. In other words, on Actual, I see a split with total amount of 51.19, and the 2 splits broken out as 12.47 and 38.72.
When I look at the csv created by exporting from Actual, on that date, all I see are 2 distinct transactions, one for 12.47 and one for 38.72. Nothing different to let you know that it was a split transaction.
@MatissJanis commented on GitHub (Feb 16, 2023):
Not sure how split transactions should look like in CSV exports. What do other apps/products/banks do? Is there an industry standard we could adopt?
@Rick-Thomas commented on GitHub (Mar 19, 2023):
Looking for Export issues I came across this question on how other apps do it...
In YNAB4 the exported file identifies split transactions with the word SPLIT followed by its order within the total of splits... Following is an example... Sorry for the Spanish, I'm in Argentina, but the example is clear...
PS: An afterthought... Don't look at the values!!! They are in Argentine Pesos, which are 370 to 1u$s !!!!! :-(
@Kidglove57 commented on GitHub (Mar 19, 2023):
Out of interest (and in response to @MatissJanis comment above), I conducted CSV exports from the Finance Apps I still have installed on my Mac, looking particularly at how splits are treated by each:
Moneywell and Actual:
Each part of the split is an entirely separate transaction - there is no indication that they are or were part of a split
Banktivity 8
The full structure of the split is preserved ie top line total with each split below
See Finance 2
Exported a transaction with the category just saying "Split" - no breakdown of that split between the transaction splits
YNAB 4:
As Rick says, all splits are labelled (Split 1, 2 etc) but no top line total.
My recollection (but I no longer have accounts to check) is that other Apps I tried over the years such as Moneywiz and Moneydance exported each split as a separate transaction.
So apart from Banktivity no apps did this really well.
@j-f1 commented on GitHub (Jun 21, 2023):
I believe this is still an issue?
@wdpk commented on GitHub (Jul 3, 2024):
based on the above posts, it didn't seem like there was an industry standard/consensus, other than it was nice to keep everything. went to look for the code and it seemed not too bad so i made a PR.
because of the way the transactions are being sorted by date though, i think split transactions on the same day with the same number of splits could be confused as to which is which (i.e. 1 of 3 appears next to 1 of 3) if they occur on same day.
@Rick-Thomas commented on GitHub (Jul 3, 2024):
I'm a total not-tech guy, but I budget a lot... No sure which are the sort fields, but if PAYEE were included in the list (depending where in the list), that would eliminate that the two 1 of 3 transactions would be together... Unless you have the same Payee, same date and same amount of split transactions in the same account and on the same day!!! 😨
@wdpk commented on GitHub (Jul 3, 2024):
Very good point. Didn't think of re-sorting based on payee. Payee is included in the export, the final CSV ends up with these: Account Date Payee Notes Category Amount Cleared
However, after doing some research, I think it is just another case of wonky-test-data. If I re-sort the transactions by date, they become appropriately grouped.
The export-to-csv code itself contains no sort-order-logic. It is strictly looking all the transactions, in whatever order presented. So if you have actual sorted by date, it will export and be sorted by date.(all-accounts-4.csv) If you have it sorted by Payee, the export would be sorted by Payee.(all-accounts-5.csv)
My PR doesn't change the sort order, it seems like copying from the view's sort is the current and best approach. I was operating from the mindset that a) this is likely for import to another system, so ordering could happen there again, or b) this is for export and data manipulation as a spreadsheet, in which case sort order is going to change anyways.
Example from the test-budget-file.
All-Accounts (4).csv - exported before re-sorting test data
All-Accounts (5).csv - export with payee sorted
All-Accounts (6).csv - export after re-sorting based on date. now is grouped by payee as well.
@Rick-Thomas commented on GitHub (Jul 4, 2024):
I looked at your three files and sorted them by ACCOUNT, DATE, PAYEE and NOTES and that sort leaves them all the same with the splits sorted in SPLIT 0 OF 3, 1 OF 3, 2 OF 3 and finally the SPLIT INTO 3... This last record is the sum of the 1st three, but it will also duplicate the value of that transaction if the file is used as is if imported into, for example, EXCEL... One would have to eliminate all records that have NO category and Notes has the word SPLIT...
The other thing that intrigues me is why GROUP is not exported... I have different groups where a category has the same name (the classic OTHER)... By exporting only CATEGORY, those categories will be lumped into one big expense instead of their corresponding group... This forces one to, sometimes, have long Category names to distinguish them from each other... Do you know if there is a technical reason for GROUP not been Exported NOR Imported???