OK, so I reach my quarter end, and run a quick reconciliation of my Starling account. Of course, it doesn’t match the statements from the bank. It never does, mostly because any two transactions with duplicated amounts from the same place get handled wrongly, still.
So I try to reconcile each individual month. But this is impossible, because the dates on the transactions in Quickfile don’t match the dates on the bank statements, so it’s not possible to pick start and end dates for reconciliation where the balance agrees with the bank. Generally the transaction is dated 2-3 days earlier in Quickfile than on the Starling accounts.
This is impossible to work with. There must be a fix to the automated feeds, surely? It’s only data!
Please, please, please fix this. I’m currently facing the choice of ditching Quickfile or ditching Starling, and I don’t want to do either!
One of the benefits of the feed is having a live feed. This works by Starling sending us a message every time you use your card - the same way as the in-app notifications work.
The issue with this is the date we have is the date of the transaction itself, in which case it should match your transaction list in your app. However, as you note, the statement goes by the settled date, which is when the transaction is finalised.
I would query with Starling if there’s a way to pull off a list of the transactions with the actual date rather than the settled date. But as it stands, with the live feed, the date will always match the transaction date rather than the settled date.
Well, I could manually download the CSV file version of the statement, and manually import that into Quickfile, and manually reconcile the account. But what are we, cavemen?
This is driving me back to NatWest, and I hate that. You should hate that, too. Are you saying that there’s no way at all to get the settled date from the API? That seems nuts, to me.
There is a way of getting it from the API, but this wouldn’t work with the live feed as we’re not able to adjust the date once it’s been imported into your transaction.
I’m going to have a chat with our development team to see if there’s anything that we can do to help here.
Yes, I just read the API docs and the Settlement time is in the response.
I would be quite happy for you to make this a user option - accurate, reconciliable accounts are way more important to me, and I’m guessing every other business out there, than absolute immediate live feed - I get the live feed from the Starling phone App anyway, having it also live in Quickfile is pointless and destructive.
I’ve just had a chat with Josh Cooke at Starling, he’s rather puzzled as to why you are having a problem and said it would be fine to give you his name as a contact.
For the record, this is the Transaction record returned by Starling. I guess you’re trying to deal with it before the “settlementTime” field has been populated, so it seems to me that there’s a pretty easy fix for this.
So just to be clear, we’re consuming Starling’s web hooks to retrieve transactions in real time, at this point we don’t know the settlement date of the transaction as it will occur at some yet undetermined point in the future.
Starling however also have a basic API method to query historical transactions, so we would need to utilise this to retrospectively poll transactions and adjust their dates accordingly. We do in fact already use this to some extent to fill in gaps that the web hooks miss.
In my opinion this is a poor design and the correct route would be for Starling to expose a setting to allow filtering of web hooks to trigger only on settled transactions (i.e. where we know it will accurately reflect the statement), this is key from an accounting perspective. This should also be straightforward for Starling to implement and far less convoluted than any 3rd party polling every single account on an hourly basis or constantly modifying historic transactions.
That’s just my thoughts on the matter, I will raise this with Starling to see what can be done.
Sounds to me like you could fix the immediate problem simply by allowing the user a switch to turn off the real-time feed, and just use the basic API method to retrieve those transactions with a settlement date?
Frankly, if you’ll pardon my bluntness, I don’t much care what you think is a poor design. What you have currently fails the basic simple test of any accounting package, in that the recorded data doesn’t match up with the statements provided by the bank. That’s accountancy 101, right there, yes? Design doesn’t get much poorer than that.
I am referring to how web hooks are triggered from Starling’s side. Why have a web hook implementation at all if you have to aggressively poll a separate feed to make sure it’s complete and accurate? Also some transactions can take several days to settle, that may be OK for your use case, but you can’t say that this will be acceptable for other QF users, people use the software in a multitude of different ways. I know from past conversations that web hooks were a key consideration when choosing Starling.
All we’re asking is that Starling consider adding a filter to their web hooks so we are notified only when a transaction is settled rather than initiated. This makes makes more sense than asking everyone of their partners to continually poll 1,000s of accounts for updates.
Since discussing this matter with Starling I am aware that they are planning an overhaul of their web hooks later this year to address this very issue. As soon as this is available we will prioritise the work to update things on our end.
Yes, I understand. I work on this stuff for a living - I thought that might have been obvious by now.
I also understand that the most technically elegant solution isn’t worth a farthing if it doesn’t meet basic user requirements, which in this case is accurate accounting records.
I’m quite happy to accept that other users might have different requirements to me, although I would be astonished if a majority of them prioritise speed of updates over accuracy of their accounting. What happens when HMRC come knocking, and want to see my bank records? “I’m sorry, it doesn’t reconcile because the supplier wants to have a system that updates in seconds, isn’t it cool?” Is likely to be met with stony silence followed by two days of them ripping my business apart.
Which is why I suggested you make it user-switchable. It would be interesting to see how many users turned on the “Yes, give me instant updates at the expense of accounting accuracy!” option.
Please, please, please give this utmost priority for a fix. I cannot handle another quarter of incorrect VAT records and non-reconciliable bank statements.
I appreciate the problem here but I would not like to lose the real time nature of these webhooks. By using Starling and Quickfile I have something I have been after since the nineties when Microsoft Money imported bank transactions direct from Barclays using a direct connection rather than going via the OFX file route that was common then.
I look at this in a different way. This is the 21st century - why are there still settlement delays? The technology is surely there to settle in real time and reverse in real time if something fails. This happens when Google take and then release £1 - there is an audit trail that transfers into Quickfile and I can choose to delete both transactions or analyse them as invoice and credit note. My choice.
I probably know the answer to my question too. There are still too many legacy systems in place in the banking industry. Barclays still use mainframes because they reckon there is no better way to handle 90 million customers. Funny how Google and Amazon cope with many millions more than that using modern technology systems. Invest in new systems or die!
Perhaps so, but out here in the real world, we have to deal with what we have to deal with. I’m quite happy with the real-time stuff being provided by the phone App, whilst my accounting package must, and I mean must reconcile with the bank accounts for tax and auditing purposes. If that means a day or two delay, I am perfectly happy with that.
In the meantime, this failure of comprehension has driven me off of Starling bank, with all their wonderfully modern ways of working, back into the arms of NatWest, who are technological dinosaurs. This makes me extremely unhappy.
Some of these comments make me sad as I am looking to switch to Starling before the year is out but I really don’t need a confusing bank feed. As you say, for the accounting integration I just want settled transactions, real time data is for the app or integration with non-accounting software IMO.
We’ll revisit this within the next couple of weeks, unfortunately it means a significant rebuild until the web hooks on Starling’s side become more granular. There’s a frustration on our side too as we weren’t fully aware of these limitations initially. Documentation was a little sparse when we started the development. For a couple of other accounting platforms (no names mentioned) Starling built the feed for them, using all their inside knowledge.
We do to some extent already use the overnight feed to plug holes in the web hooks, therefore we can probably extend this to just completely handle transactions based on settlement dates. We do want to get this right as I believe Starling will only increase in popularity over time.
I appreciate the offer, although we’ve potentially found a way to address this issue for now without too much additional work. Hopefully we can have this fixed by next week.
Are you able to confirm if it’s just card payments out where you’re seeing date discrepancies? We are looking to add a condition to ignore these outbound card payments on the hooks, then import them via the feed when they are presented with settled status.