The data structure of our existing CSV export is a bit out of date.
If you could change anything in the data structure, what would you do?
8 Likes
Date & time in separate columns would be a good start. I realise itās easy enough to extrapolate it yourself, but itās easier if itās done for you.
7 Likes
I think options built around where the output will be used is the best route forward?
CSV for Excel
CSV for [finance app A]
But the date/time piece is probably key.
So, is this part of a āWhatās Nextā piece of work? #soon
1 Like
use of colours to differentiate categories
But what happens when (if?!) we get custom categories? Hmmm set them to match the colour in the app I guess?
1 Like
I donāt think you can do that in a CSV.
2 Likes
I would suggest - Time is 09:33:50 Zulu - a term for UCT as used in Military and Aviation settings.
R-
Personally I found the ādescriptionā column problematic. Itās tricky to extract a list of retailers from this column since its used for other info such as whether its a pot transfer. I found a workaround that involved showing only the items that included a bunch of spaces, since the retailer information is typically formatted with large spaces between the name, region and nation. Perhaps a column could be added that provides the type of transaction; Pot Transfer, Faster Payment, P2P payment, Direct Debit, Card Check, card payment, cash withdrawal. So that this is kept separate from the retailer, payer and recipient information.
I also agree that the time date format for the ācreatedā column is not very user friendly when brought into google sheets or excel.
4 Likes
This is correct, itās an ISO (International Organization for Standardization) date/time format, itās the standard we use at work too.
I know WHAT it is but no idea why itās in a CSV export from a consumer app.
User friendly date preferred even if it doesnāt conform to an ISO standard
1 Like
Please please keep ISO 8601.
I have transactions in multiple time zones. If the data is split it makes my life harder.
-
MCC codes
-
TX type (Contactless, Apple Pay, Mag Stripe, Chip) Lloyds does this one well.
-
CVM method
3 Likes
My apologies - I misunderstood.
R-
1 Like
No worries!
This is the point of using iso8601 formatting; it avoids any ambiguity. Iād prefer it to stay as it is but having an extra āReadableā version probably wouldnāt hurt.
I get what youāre saying but Iād be really interested in how much of the user base actually bothers exporting transactions and (weāll never get data on this) how many of these arenāt familiar enough with Excel to achieve what they want.
3 Likes
No reason they canāt do both.
For those of us who Excel now and then, a nicer format for that would help.
For those who need the ISO style data, then retain that.
Iām in the āgive me it like a bank statementā side of the argument, and they never ever come with timezone info in them (historically/legacy etc I know).
But yeah, no reason they canāt do both/all/more.
Ehhh thanks, Iām aware of the options, but I canāt (easily) import a PDF into Excel.
Personally I want the lowest friction solution. Export to XLS, open in Excel and have the data āunderstoodā without having to do any formatting/transformations.
Anyway, what other options do other people want?
I thought the date was always in UTC regardless of the local time at the merchant location? 
This seems overkill? Thereās so many MCC (Mastercard Merchant Codes - list) that it makes them of little use to look at aggregate data, also lots of merchants have the wrong MCC.
Whatās the use case for these two?
Very few customers do a manual export, more people use the IFTTT integration to auto-export (and thatās also low).
1 Like
Is there a reason why the IFTTT auto-export contains less information than the manual export?