CSV Exports

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.

5 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

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

:man_shrugging: :grinning:

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.

3 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.

The PDF export does have a more readable date if that works for you?

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? :thinking:

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?