Yes, this is what I thought.
The Management Accounts are a disaster before they are altered by myself.
...and there's no danger of anything getting posted to Depreciation as [he or she] doesn't post depreciation as "it isn't real so there's no point".
No. Just use your common sense - a resource apparently overlooked by your colleague.
Much depends on what information management require.
Personally, I'm in favour of erring on overdoing the analysis. It's easier to add numbers together than sift through to take numbers out of a nominal account.
I didn't think so.
I totally agree!
I've been an accountant for 20 years and I've never seen anything like it - the audit adjustments are several pages long each year due to the lack of knowledge.
The directors brought me in to sort out the mess but, at the same time, they don't want me to upset the Accounts Manager...the only way to achieve that is to keep everything the same and do nothing.
I prepare the Management Accounts each month by (pretty much) taking a raw list of transactions out of the system and re-analysing each one to where I know it should go, unfortunately, a lot of transactions slip through the net due to the volume and I get department heads and directors complaining each month that they're taking costs that don't belong to them.
Previous attempts to confront the accounts manager have just led to a face-off and conversations generally go like this...
"job adverts should go to Recruitment"
"no, it's Marketing"
"Marketing activities are really only things that intend to increase sales"
"Yes, and by having more staff, we can achieve more sales"
So, just to complete this thread - I had a word with the payroll manager, and yes, it turns out that the pensions had been set up incorrectly in Iris and it looks like we've actually been paying the Ee's contribution to the employee on top of their salary!
Thanks to everyone for confirming that my instincts are still functioning correctly :-)
Euan MacLennan wrote:
... but it's all a guessing game!
Something's definitely wrong though - I didn't wan't to go storming in on the payroll manager making accusations based solely on instinct without a few other opinions.
I've also checked the main company's payroll and, despite being on the same pension scheme, Iris is set up completely differently - so I think I have enough evidence to now go and have a chat!
Looking at the reports from Iris, the 'Company Totals' report shows Gross pay as Net Pensions + Salary (9.18+4636.67=4645.85) and, at the bottom in the 'Cost of Payroll section the 4645.85 is added to Er's NI (which comes to 4994.64).
If I look at the 'Payroll Summary' report, the Ee's pension contribution is shown as an after tax addition to payroll (therefore, tax/NI are calculated before the pension is added).
Shouldn't the pension contribution be taken as an after tax deduction rather than an addition?
You're probably correct - I was initially confused as to why the Ee's pension contribution is added to the gross salary.
...this is what I'm thinking - it looks as if the Ee's pension amount has been paid over to the employee.
Surely the double entry to get the Ee's pension into Pensions Control would be Debit Salaries Control and Credit Pensions Control ?
I wouldn't be able to do anything without SQL/ODBC. The standard reports in the system are inadequate to say the least...and a lot of them don't work.
...I was told "we don't do balance sheets" when I started! It still sends a shiver down my spine!
" there's no way of tying up an invoice with a receipt"
Well I can't believe that's actually true, otherwise you've got absolutely no way of knowing what's in your trade debtors listing and due from each client.
It's an unbelievably bad system from the 90's.
From a database point of view, receipts lines only contain the matter ref and don't contain a reference for the invoice that it's paying. So, when looking at the matter as a whole, you can see the total balance and every transaction within but there isn't a direct payment allocation.
The Invoice line in the database does get updated when a payment is made, but it only gets a 'paid' flag and an amount that was paid (whereas a modern system would also include the payment transaction number so that the payment can be linked to the invoice).
The Aged Debt is basically an aged listing of all invoices where the 'paid' flag <> 0 and the paid amount <> 0.
There are two many transactions to tackle this manually but I can calculate debtor days per department and use that as a basis of forecasting the new year.
We do work in the following areas..
- Residential conveyancing
- Commercial Conveyancing
- Civil Litigation
- Insurance costs
- Wills & Probate
- Employment law
- Commercial law
So we do have a diverse range of debtor days, each worthy of a separate calculation.
UPDATE - while digging around in SQL I have just found that each invoice line does have a 'date paid' field, so that's that problem solved!
yep - I get that now, the 77 is just a proportion of annual sales where the annual sales equates to 365.
...and the receipts profile is something completely different.