Yes, seems to be just outgoing card payments. Refunds to the card, and bank tranfers from external accounts, are both set up with the correct dates.
On the weekend we made an update to disregard instant notifications on card payments. We’re now using the overnight feed to query and import settled card transactions. This will then ensure that the dates align perfectly to your bank statement.
We’re closely monitoring this to ensure that everything is coming through correctly. If you have any observations / questions from your account you’d like to discuss just private message me or @QFSupport here.
Glenn, that’s extremely quick work, thanks! I’ll monitor the transactions and update you in a few days.
No problem, although I should make you aware that the transactions should now start coming through with the settlement dates as from today. We had to make a few minor adjustments, some of which were deployed to the live site just earlier today.
We are monitoring this with two of our own internal Starling accounts but feel free to send us any observations you may have.
Looks like you still have something a little awry, I’m afraid. I just had four transactions from the 11th drop into my account, which appear on my Starling account with a settled date of the 13th. So far, so good, but the four transactions all have a date of the 11th in QF, i.e. the date they were performed, rather than today’s date.
I think we’re getting closer, though.
We were aware of that issue and in fact it should have gone live on Wednesday. We’ve redeployed again today so it should be fixed now. The transactions picked up on the feed should be inserting with the settlement dates not when the transactions were made. We’ll keep an eye on this.
Good stuff, thanks. I’ll keep an eye on it this end, too.
I’ve just had a batch of payments come through dated yesterday (the 15th) which match up perfectly with the statement, so that looks good.
I’ll put some work in next week to ensure that the QF balance on the account matches up with the real balance, and then the full proof will be whether I can do a reconciliation at the end of August without too much fiddling.
Thanks for your work so far, it’s looking good.
Similar to @Geoff.Campbell I’m seeing discrepancies in my feed vs the statements also, although in my case it’s that the inserts into QuickFile are actually a day EARLY i.e. that my account feed is showing transactions a day previous to that displayed on my statement/in app feed.
Here’s a sample from the statement showing the last few days activity (it’s a new account)
Heres’s the same shot from QuickFile:
As you can see the credits deposited are showing a day earlier within QuickFile
£58.85 QF 22nd/Starling 23rd
£106.65 QF 23rd/Starling 24th (today)
At a guess, it looks like there’s an error in how the transaction times are being interpreted/logic applied when being transposed from the feed - checking the app all these credits were applied to my account/processed by Starling at 12.01am on the respective days.
Looking at the data we receive from Starling, it does seem to be related to the times.
I’ve asked someone to look at that. There are a few which are correct (e.g. the £41.71 on 22/07 and the payment to us) but these settled during the day rather than around midnight.
UTC vs BST issue perhaps?
Morning @QFMathew - Do you have any update from the team on this as I’m still seeing errors in my statement: todays payments processed overnight have imported into QF with yesterdays date for example.
As an aside I’m also seeing that QF’s internal ‘Tagging Rules’ don’t seem to fire from these feeds either - I.e. rules preset in QF (which have confirmed matches) do NOT trigger an automatic match on import of new transactions from the Starling Bank feed.
From the Bank Statement Screen:
I have checked and confirmed the rules each morning for last few days and either setting ‘Starts With…’ or ‘Contains…’ in the rule correctly identifies matching entries on save as expected, yet fails to trigger updates on any new imports from the automated feeds on the following day(s).
In line with @ian_roberts I’d think this is likely another formatting error - possibly that the feed is coming through with extra spaces/special characters/encoding etc. preventing them from matching?
I know my usage compared to others will be very minor but I hadn’t expected to be having to baby sit it so closely and in effect Beta test the quality of the workflow. I appreciate that the API feed from Starling themselves as @Glenn mentioned earlier in this thread isn’t the best and is due for improvement later in the year but its clear to me that the integration into QF isn’t as polished or complete as it should be.
Forgive me if that sounds overly critical - I have no issue with the very reasonable charge for using the automated Starling feeds, but I’d be incredibly concerned right now that this could be creating more issues and inaccuracies for users than it attempts to solve. I’m sure I’m not the only user who performs the book keeping admin in batches, and it would be incredibly frustrating to sit down in a few months time to realise that there were potentially hundreds of manual adjustments required to bring the records inline…especially so if you’ve also paid a premium for the privilege.
Could yourself or Glen confirm the following as a priority please:
- The status of the feed and progress investigating the errors
- An expected ETA on a resolution
Depending upon the above I think you also need to consider:
- Communication to affected users with suggested steps to fix historic records
- Method for suspending/terminating the feeds whilst awaiting a resolution
- Temporarily suspend the option of purchasing the feed for new users
This might sound overly dramatic, but I’m very worried (on QF’s behalf ) that depending on the numbers of users currently subscribed to the Starling Feeds, you potentially have hundreds (if not thousands) of transactions being created automatically each day and whilst the nature of the problem itself is fairly trivial, the impact and manual work required to resolve for end users would not be.
We are looking into this issue at the moment, we don’t currently have any updates but will be sure to let you know if/when a fix has been issued.
We have 2 internal Starling accounts we use for testing purposes, but it doesn’t always simulate all the different scenarios others will encounter.
The issues highlighted here should be reviewed and fixed by Monday.
EDIT (29th July):
The issue with the incorrect date assignment affected a relatively small number of entries occuring between 00:00 and 01:00 due to a missing conversion from UTC to BST time. We fixed this and deployed the update earlier today. We will continue to monitor going forward.
@Scruffies we could not see any obvious reason why the bank tagging rule failed to trigger. We’ll continue to look into this tomorrow.
Morning @Glenn - ahah that looks much better thank you
I’m still unsure why the ‘auto tagging’ isn’t firing against these entries though …I’m around for the next day or two, if I can be any help in troubleshooting etc.
So regarding the triggering of bank tagging rules, this is due to the way the web hook initialy supplies just the counter party name e.g.
"iZettle ". We insert that as the reference on the bank entry and at this point we cross-check against bank tagging rules.
Later we query the Starling feed and amend any bank entries with a fuller description that appends a reference field, in this case
SCRUFFIES PET GROO. There’s usually a gap of 6-7 hours before that update is made.
A simple way to solve this would be to edit your tagging rule to
start with: iZettle, this should then ensure that your iZettle transfers are always matched and processed.
This mornings feed has been processed against the correct date and the bank tagging rules have fired successfully - as always a big thank you to you and the team for the fantastic support you offer end users, much appreciated!
This topic was automatically closed after 5 days. New replies are no longer allowed.