I claim that there is a discrepancy between the online batch ‘automated’ verification service and the offline telephone verificaton service. In order to justify my claims, I have one scenario in which I lay down evidence which proves the discrepancy beyond all reasonable doubt. As the development manager, I am also responsible for ensuring that all of our customers are supported, and we have had many customers open support incidents with us to query why an automatic online verificaton has returned “unmatched” (that’s a 30% deduction – ouch to any business cashflow, regardless of whether you ‘offset’ it later) whereas a phonecall to the new CIS verification hotline quickly resolves the subcontractor under scrutiny as being matched.
Perhaps these errors only account for a small percentage of actual verifications performed. It is possible that in arguing “frequent” errors my definition is different to that of HM Revenue & Customs. I would suggest that any more than 0.2% of verifications being returned incorrectly unmatched would be “frequent” enough to cause severe cashflow problems for subcontractors, who, by working for a supplier using a batch verification mechanism without manual checks and overrides of tax treatment status, could suffer as a result. I call this far too “frequent”.
At Evolved Software Studios, we have written crucial medical software used to check blood transfusions. And a messaging system more complex than verifications to assist in the diagnosis of eye diseases. We’ve even worked on a project for the Ministry of Defence. The failure rate in these industries of even 0.2% would mean deaths and we wouldn’t get paid. So, why when we report to HM Revenue & Customs – daily – that our customers are facing damaging their supply chain, do we have to wait (three weeks and counting) and do our customers tax queries not get treated with the same degree of care?
What about my evidence?
Well, this is a blog and I don’t want it to be too boring. Suffice to say that on the 18th July 2007, one of our customers provided us with a telephone verification reference number, and confirmed the data in the XML file output as being identical to the data used to verify a subcontractor over the phone. Online was unmatched, telephone was matched. Data provided to HMRC turns out to have absolutely no reason why an unmatched result should be returned.
I have my ideas as to why two different results were returned. Because there are two different front-end / business process / business rules; systems.
Anecdotally, it happens frequently to almost all customers in some way or another. Subcontractors may not have the correct name (or may enter nicknames instead of registered names), or may use the trading name field, instead of the name fields. Either way, if you’re using the online services – unmatched. If you telephone – matched. If you happen to call the phone verification service, you’ll get to speak to a human being who isn’t going to berate you for talking in lowercase, or getting the surname or forename the wrong way around, or using a nickname. “Mike”, oh, you mean “Michael?”, yes, he’s net 20%.. unmatched you say? nooo, computer says 20%”, says the proverbial computer operator…
When did someone in a call center last say to you, “Sorry. Call Terminated. You spoke in lower case.”? Or how about this, “Please provide everything you know about the customer, after the tone…. “, “Sorry, you said something that we didn’t quite expect. Unmatched. Call Terminated.”. Of course not, that would be silly! So why do we code our systems like this? The cynical would say that HM Revenue & Customs want you to be unmatched. Oh to suggest such a thing would be unkind.
Online, if your data set isn’t right – computer says no (unmatched). If you use a Contractor ERP, CRM or other solution, you are likely to hold a LOT of information on your subcontractors. Over and beyond the minimum data set of a National Insurance Number and a name. God forbid if, in your carelessness, you spelt the name wrong or provided a bit too much information – you’ve dug a hole for yourself for the online systems. We have in the past, recommended that our customers stop using so much data – perhaps stripping out addresses, trading names, telephone number etc. Going back to grass roots National Insurance Number, and a name. That usually always works. If you have more than that information in your database, you might be stinging your subcontractors out of their correct tax treatment status.
Of course, we know what works in practice, because we have the experimental, empirical evidence. I have been asking for the XSLT, or the business rules. The specification HM Revenue & Customs had written for Cap Gemini. Someone somewhere, is a software contractor, much like I or one of my colleagues – working on this system. Expressing the search criterion as a mathematical expression. These rules are known, but they are top secret… shhhh, HM Revenue & Customs don’t want you to know how they match people….
Waffling aside, I have many more examples, spanning several contractors. Many of whom have angrily told me that the new CIS helpline has told them to “speak to their vendors” or “check the software user manual”. I could spend all day working on the XML, playing trial and error on the live system with one of our customers live tax credentials – but we’re not allowed access to the live system, so how can we help any customer who has a query regarding live data? We simply contact HM Revenue & Customs with the query, and wait to be ignored. The anonymous “spokesman”, speaking from an assumed protected position of civil servanthood states that all the discrepancies are due to different data being provided on the phone as to online. This begs the question, why is different data being asked for then? Why, if the two systems should be the same, are the business processes that rule them – not?
Until this point, I have been advising our customers with a positive angle, saying that the phone verification service is better than the online one, since a human on the other end of a telephone can assist in tracking down a subcontractor. But as the writer of the article points out – there is absolutely no reason why any contractor should do this. Sure, a small contractor wanting to look after their supply chain might take exception to an unmatched response, phoning the revenue for advice – but what about a main contractor with THOUSANDS of subcontractors, whose systems are fully automated?
I assert that the phone system provides a “buffer” which allows for a larger degree of matching error than the online system – which is very tight. HM Revenue & Customs run two completely different systems for online and offline verification, regardless of the spin that you might hear from their “spokesman”. Either they should be telling customers who call – “sorry, you gave me an incorrect national insurance number. This person is unmatched. Deduct 30%. Computer says no. Goodbye.” – OR – the online matching system should work in a more flexible way, allowing for the same degree of error (perhaps allowing 3 out of 4 fields to be matched correctly = matched).
What could cause a known subcontractor to be returned unmatched then?
The trouble is even as a software development house, we are not priviledged with the information on how things work from HM Revenue & Customs side. Quite often, they don’t even know (I had a discussion with them last month on lock out periods, which turned out to not exist). It’s not any individual’s fault, but some documentation would be nice to add to the pile. At least it could give us something to tell our customers when it looks like our software isn’t “matching” records correctly.
Since April 2007, here is what we have learned;
For every subcontractor undergoing verification:
If HM Revenue & Customs have a National Insurance Number for the subcontractor and you don’t provide it – unmatched (this rule may not apply on the phone verification service though)
If HM Revenue & Customs have a different UTR or National Insurance Number to yours – unmatched (make sure your data is 100% correct before making verifications)
There is a completely random chance that your verification (or monthly return) will contain something that makes the process on the HM Revenue & Customs server fall over. You won’t know if this is you until you try. This is caused by something in one of your subcontractor records that is perfectly acceptable, but HM Revenue & Customs can’t handle it. Call it bad testing if you like, I call it fustrating when users are logging tickets with us saying “your software doesn’t work, it’s been waiting a week for a reply for my verifications/monthly return”. The trick we recommend to customers is to isolate the subcontractor record by verifying alphabetically in batches. If you don’t get a response, halve your batch and try again. Try all the subcontractors with a trading name starting with “A’s” and “B’s” together. If it doesn’t work, just try “A’s”. If you have tens of thousands of subcontractors, you’re going to struggle. (To be fair, we haven’t had a report of this in a couple of weeks now, is it fixed? Who knows. HM Revenue & Customs don’t publish a version or change log)
If you’re getting unmatched on a subcontractor, try reducing the amount of information you hold about them. Perhaps erase their address, or erase their UTR from your records. Sounds daft, doens’t it? But it might work. Remember, you are partaking in a glorious multiple-choice get-it-wrong-and-you’re-unmatched quiz. Think of it like Jeopardy. The less “answers” you give the revenue, the less likelyhood you’re going get it wrong and accidentally trip the unmatched wire.
If you phone for a verification, you are going to get a better class response than if you go online. Simple. Computers do exactly what they are told, if you do an online verification HM Revenue & Customs are matching letter for letter, number for number. If you go on the phone you will get a person who will work with you on getting someone verified. The human in the loop is not following the same rules as the online service. This is, in a way, a good thing. A human will always use their own intelligence to match the fields and see if they can find who you are looking for. We have never heard of the phone service coming back unmatched where software matches.
Putting personal names into Trading Names (according to discussions with HMRC, this shouldn’t cause an unmatched… but it does – trust me)
These are just undocumented examples which we have learned from feedback from our great customers. We have tested and seen these, and confirmed them with HM Revenue & Customs. I’ve asked if there are any more, but who knows? Maybe if “the system” just doesn’t like you, you’ll get unmatched too. Come on HMRC, if you really want to stop rumours why not join the rest of the world in adopting some proper science rather than contorted spin? I’m talking about standards, fully testable evidence and no-nonsense documentation. Even the new CIS helpline runs off scripts. Scripts they won’t publish. Why not? Surely if these hidden business rules were made clear and those helpline scripts published we would, as a software house be able to advise customers directly.
After all, customers call us to complain after being told to “contact the vendor who supplied your software”, presumably by a script-reading temp in a “computer says no” voice.
It is tiring being blamed for faults in a third party online service that really should have been written by an innovative private software company 🙂 However, I feel more fustration on behalf of those subcontractors, moving from site to site – working for large contractors – who – may fall foul of one of the “unmatched” bombs in the proverbial minefield of new CIS online.
It’s 23:57, I’ve been working on these issues all day, and I haven’t proof read my article. I hope you, dear reader, can see past me waxing lyrical about the inane and boorish comments from HM Revenue & Customs to date and gain some value.
If, in my ramblings, I have managed to save one family business from being unfairly cash-flow punished, it would have been worth it. As ever, this is my opinion, feel free to leave comments.