Member Since: 20th Feb 2007
Self employed IT Consultant
27th Mar 2019
My guess is that this entire concept stands a chance of being at least as effective as the BACS tag metadata in RTI filings.
Which is to say, not effective at all, at anything.
24th Nov 2016
The design of RTI was fundamentally flawed. Its biggest flaw is the inability of agents/employers/bureaus to access detailed statements of account (at employee level) of what is held in the RTI system. So once the high level numbers being claimed by HMRC are wrong (which happens far too frequently) there is no way of working out where the error has arisen.
This was frequently pointed out (in 3rd party software developer meetings with HMRC) as a sure and certain failure point of the original design. And repeated assurances were given in those meetings that the issue would be looked at. Nothing ever happened because the people implementing RTI at HMRC didn't care; they knew that they'd have moved on by the time the chickens roosted and the design was "already done and paid for". So much for the year of pilot operations (exhibiting numerous reconciliation failures) which didn't influence the final design!
No-one would operate a credit card account or bank account on the basis of accrued historical summary totals. The very idea is laughable as it would make reconciliation a hopeless task on even the simplest lowest volume account. Yet this is how RTI (with numerous running totals of pay/tax/SxP/loan/NI/etc) is expected to work. Of course it fails!!!
10th Oct 2014
Apples and Oranges...
Hello Buttercup, Just to clarify (from a no longer biased point of view, so this is intended to be helpful rather than a marketing push for any particular solution).
The figures you're quoting are for products that solve different problems. Like comparing the price of a smart family runabout with a delivery lorry. Someone might want/need one or both of those things but price comparison between them isn't meaningful because they don't answer the same need even though they may both be excellent vehicles and one may be far cheaper than the other.
In particular the guide price from the OP for AE is for a full compliance solution that includes a web portal that handles all the communications to employees. If you don't want that then Iris has payroll products (such as 12Pay's current offering) priced broadly equivalently to Moneysoft; maybe a little bit more including AE assessment/calculation/filing but not so different in price that price ought to be a determining factor for most buyers (as opposed to other factors such as product features/support/ease/robustness etc)
Moneysoft may or may not offer full AE compliance at some point in the future. So far as I am aware (please correct me, anyone, if I'm wrong) they have not stated any intention to do so at the moment.
So it isn't relevant to compare the cost of Open Enrol with the cost of Moneysoft. They don't do the same thing. That of course doesn't mean that you or anyone else has to agree that you believe that Open Enrol is worth the suggested prices to you; that is a separate discussion in which everyone is free to have their own opinion. Doubtless some will buy it and others won't. Unfortunately the AE compliance rules are crazy and have been constructed without any reference to making it easy for employers to comply.
I hope that helps.
9th Oct 2014
Auto Enrolment development
I fully understand the decision as writing the interfaces for AE must be a huge undertaking. I am disappointed though as 12Pay is a fantastic product and my concern is that it will go the same was as TAS after Sage purchased it .... Good luck Tom and thank you for all of your support.
Thanks for the kind words Sonia.
Most of the development work for AE handling amounting to assessment/enrolment/calculation/reporting/exporting for 5-6 of the highest-profile pension providers had already been done while I was still involved, partly before the sale and partly during the handover process. In fact during the handover period the Iris software development team had a very clever technical idea about how to generate the text files for the pension providers with particular reference to being able to change/add to all of their different formats "on the fly" without having to send sites completely new builds of the 12Pay software if something was wrong or needed altering. So that part of the process is definitely technically better than it would have been if Iris weren't involved.
That project broadly took 12Pay to the same level as I understand eg Moneysoft to be aiming for; ie handling the assessment/calculation/filing, but NOT the compliance communications etc. As other developers/experts have pointed out the whole compliance area really requires a large, complex, additional product which yes, I wasn't sure if 12Pay would offer in its entirety, or even at all. However Iris has already developed such a product (called Open Enrol I think), and 12Pay will interface with that soon, if it doesn't already. The assimilation into the Iris stable of payroll products means that 12Pay won't have to re-invent that particular wheel, instead it can share Iris's AE compliance portal with Iris's other payroll products. This is a major potential benefit related to the acquisition for 12Pay's client base.
9th Oct 2014
Just spotted this thread...
So this seems like a good moment to thank the AW members who have contributed to conversations about 12Pay.
I'd also like to give a friendly wave to the other payroll supplier professionals who post here from time to time. Although we all theoretically competed for clients it never felt that way and we had many useful private mail conversations here as well as our public contributions. It often helped to discover that other software developers were experiencing the same issues (with eg HMRC) as us.
Finally a specific mention for Eaun McLennan, a prolific payroll contributor here well known for his admiration for Moneysoft, but he is always fair and kind about 12Pay in these threads.
1st Aug 2013
A sensible design...
Peter Tucker wrote:
The PAYE End of year system had a simple cross referenceing system with the individuals annual Earnings etc. being provided on Forms P14 and the summary of these details being provided on Form P35, for each and every Employer / PAYE Reference in the UK.
This logic does not appear to have followed through to the new, more regular RTI system, since only the information relating to the Individual Employee is reported through to HMRC.
This means that HMRC do not have a complete weekly / monthly statement of individual and total PAYE information. They merely have a partial picture and therefore there are several Employers and Payroll Teams who are rying to explain to HMRC Debt Management that duff records do not actually means any underpayment in liability, something that other areas of HMRC would agree with, I suspect.
While recognising that the PAYE End of Year system was introduced in the 1940's, many would say that arithmetic and simple accounting has remained unchanged since those far off days, notwithstanding the amazing developments in electronic communications.
Indeed, a sensible design for phase 1 of RTI would have been to simply file 12 monthly interim P14/P35 sets. Such a design would have been trivial to add to most payroll software since the logic was already present. And the design is self-correcting month by month, and the user is aware of the total liability that they're filing for, rather than lots of oddments being added up to justify a total liability leading to the arguments that we're now seeing between clients and the accounts office.
But they had to have filing "On Or Before the Date of Payment" to support the political needs of Universal Credit, which as we speak appears to be going nowhere for 1,001 entirely predictable reasons. So the RTI specification ended up having the kitchen sink thrown into it.
11th Jul 2013
Accounts Office and Tax Office disconnect
In the old system it was a validation requirement that the filed P14s expressing individual employee information should add up to the filed P35, which expressed the total owed by an employer to HMRC. The two concepts were naturally tightly coupled, so that the accounts-office demand at year end should never come as a surprise to the employer, since the employer had prepared and signed off on the P35 totals as part of their natural year end process.
Under RTI this natural connection between individual employee deductions and the amount an employer is chased for by the accounts office has been removed. Employers file a disparate collection of documents through the month and HMRC adds them all up and passes the total to the accounts office. So a potential disconnect arises between the amount the employer expects to pay, as shown on a P32 document that they produce locally, and the amount HMRC demands, as they've derived from adding up all of the individual filings they have received.
This disconnect is coupled with HMRC becoming more active in pursuing employers the amount that HMRC feels that they owe. A natural reaction to receiving the information in real time. So we're already seeing instances of clients being chased for sums which aren't what the client thinks they've filed, but the accounts office just has a total so no reconciliation is possible. A monthly interim P35/P14 process would have actually been much easier for everyone, but then HMRC wouldn't have been able to pretend that they were making things simpler by getting rid of the P35.
1st Jul 2013
Most serious RTI issue
Mike Nicholas wrote:
In my opinion, this reconciliation problem is the most serious issue to have been identified so far under RTI. With hindsight, greater controls were (and remain) required – such as a P35-like summary for each batch of FPS returns so that any discrepancy can be isolated by HMRC with feedback to the originator.
Agreed. The equivalent of P35/P14 monthly would help.
The ability to file a DPS request asking for the details for HMRC's figures at employee level would be invaluable.
1st Jul 2013
Correct me if I am missing something here, but on my payroll software, it shows me the totals before I send them, so it is fairly easy to check. If they then make a mistake with it later on, it is a nuisance, but ultimately it is their job to check their own work. They don't pay me to do it. It would be useful to be able to check the figures online, but ultimately, reconciling their own accounts is their job - provided the data is submitted correctly, that is their problem.
Or am I misunderstanding the point of the article?
The problem arises when HMRC claims that the amount you owe for the month/quarter isn't the same as the amount your payroll software P32 is telling you.
We have seen several instances of this, but not yet a single confirmed instance where the payroll software was at fault or the amount filed was incorrect. But because all the accounts office and tax office seems to have is the total figures you can't tell *why* there is a difference between their demand and what you think they owe. And some accounts office operators take the (ridiculous) line that their system must be perfect therefore the error is the client or their payroll software. In one case the amount claimed by HMRC was more than 10x the client's P32 figure.
We've been advocating since RTI was first on the drawing board that there has to be the possibility of a reconciliation process, where the payroll software can draw back employee level detail from HMRC's systems, and compare that with the current P11s. Every time we suggested it, everyone agrees that the system needs this facility, but nothing ever happens.
14th Jun 2013
Is this the concession that applies to almost no businesses?
I was aware of a 6 month concession that companies that pay their employees weekly but calculate PAYE monthly could report RTI monthly. That concession is totally irrelevant to 99.9% of small businesses, so extending it to a year isn't really much of a concession.
The wording of the article looks quite dangerous. There is an implication there that all small companies need only report 12 times a year under the concession, even if they pay their employees weekly, which simply isn't the case, so far as I am aware. The problem is that over-hyped reporting of concessions makes small employers think that they're "off the hook".