actual: [Bug]: GoCardLess does not import all transactions for credit card (Bank of Norwegian, SE/DK)
Verified issue does not already exist?
- I have searched and found no existing issue
What happened?
Similar to the issues stated in https://github.com/actualbudget/actual/issues/724#issuecomment-1576331381 by @Inrego, when enabling a credit card from the Bank of Norwegian (Swedish in my case) - the integration does not import all transaction but only:
- deposits
- pending transactions
- transactions where
valueDate
is lower than current day (IMHO this is where the problem is for credit cards)
For context, on July 24th this is the last transaction that actual sees under Available (first 10) transactions properties for new integration of institution in sortTransactions function logs:
{
transactionId: 'xxx',
entryReference: 'xxx',
bookingDate: '2023-06-15',
valueDate: '2023-06-28',
transactionAmount: { amount: '-15', currency: 'SEK' },
currencyExchange: [
{
sourceCurrency: 'SEK',
exchangeRate: '1.00',
targetCurrency: 'SEK',
quotationDate: '2023-06-14T00:00:00.0000000',
},
],
creditorName: 'HEMKOP HUVUSTA',
remittanceInformationUnstructured: 'HEMKOP HUVUSTA SOLNA SE',
additionalInformation: 'MISC FOOD STORES - DEFAULT',
proprietaryBankTransactionCode:'Köp',
internalTransactionId: 'xxx',
},
there were a lot dozen more transaction made between June 15th and July 24th. In the example above: the bookingDate
points to the date when the payment was made.
When i perform a raw API call to gocardless - they correctly return a full list of transactions, example of the transaction that i performed this month (18th of July):
{
"transactionId": "xxx",
"bookingDate": "2023-07-18",
"valueDate": "2023-08-28",
"transactionAmount": {
"amount": "-250.43",
"currency": "SEK"
},
"currencyExchange": [
{
"sourceCurrency": "SEK",
"exchangeRate": "1.00",
"targetCurrency": "SEK",
"quotationDate": "2023-07-15T00:00:00.0000000"
}
],
"creditorName": "OKQ8 ",
"remittanceInformationUnstructured": "OKQ8 SOLLENTUNA SE ",
"additionalInformation": "Automated Fuel Dispensers ",
"proprietaryBankTransactionCode": "Köp",
"internalTransactionId": "xxx"
},
The problem with credit cards *at least the Swedish ones
After contacting GoCardLess support, this is the message they received from the bank: Here’s what the bank says about the valueDates in the future:
For the credit card, you have interest free credit for up to 45 days. For Sweden we invoice from 15th of last month to 15th of next month, with an additional ~14 days to complete payment. So the 15th of August this customer will receive invoice for the transaction made 15th of July, with a due date (
valueDate
) of August 28th.
The verdict
Following the explanation from the bank, the last transaction example (with creditorName
“OKQ8”) the valueDate
is August 28th which is the last date when to pay for the purchase interest free. And since valueDate
is in the future - Actual will not import this transaction and will simply ignore it.
IMHO, for this specific bank (since it’s a credit card) - Actual must take bookingDate
instead of valueDate
. I am not sure the same logic applies for all credit cards, but might be something to look into.
What error did you receive?
No response
Where are you hosting Actual?
Locally via Yarn
What browsers are you seeing the problem on?
Other
Operating System
Mac OSX
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 16 (9 by maintainers)
Commits related to this issue
- Stop setting endDate when fetching GoCardless transactions This breaks fetching transactions where the valueDate is in the future. While the GoCardless documentation says this should never happen, it... — committed to kyrias/actual by kyrias a year ago
- Stop setting endDate when fetching GoCardless transactions This breaks fetching transactions where the valueDate is in the future. While the GoCardless documentation says this should never happen, it... — committed to kyrias/actual by kyrias a year ago
- Stop setting endDate when fetching GoCardless transactions (#1493) This breaks fetching transactions where the valueDate is in the future. While the GoCardless documentation says this should never h... — committed to actualbudget/actual by kyrias a year ago
- Stop setting endDate when fetching GoCardless transactions (#1493) This breaks fetching transactions where the valueDate is in the future. While the GoCardless documentation says this should never h... — committed to FlorianLang06/actual by kyrias a year ago
Correct. 😃
Aah, I’m blind. I see it now. I haven’t read trough the whole discussion in https://github.com/actualbudget/actual-server/pull/237 though, so I don’t have the full context of the issue for Bank Norwegian as implemented there (with the pending transactions and whatnot). But at least in this issue the only problem mentioned is with the
valueDate
not being the expected value for credit cards? Which seems to align with the behavior I’m seeing with Danske Bank.I don’t know if Danske Bank shows the same behavior with pending transactions (I don’t have any atm so I can’t check. I’ll make sure to validate that before I make a PR though).
I guess my question here is that it is correct for me to assume that the right path forward would be to implement a similar bank integration as in https://github.com/actualbudget/actual-server/pull/237, at least for the booked transactions (starting balance seems to be the same as well)?
Here’s the account properties for my danish branch account:
I’d appreciate it if one or both of you would be able to help test out my changes in actualbudget/actual-server#237.
From the GoCardless documentatio:
This description seems… not very helpful for me, but I found this one instead from lewik.org which gives the definition in the context of PSD2:
That to me makes it sound like we should not be using
valueDate
in Actual, or at the very least it should not be the primary value used. From the rest of the GoCardless documentation it sounds to me like if anything we should usebookingDate || bookingDateTime || valueDate || valueDateTime
to make sure that we hopefully get some date.