Skip to main content

HR, Payroll and Project Management in One System

What actually breaks at the seam between two systems, and what one system does — and does not — put right.

Where we stand

We make an HR platform that also runs projects and invoicing, so we have an obvious interest in the conclusion. This post is written to be useful even if you never buy anything from us: the failures are described as mechanisms you can check against your own systems, every statutory figure links to the government page it was read from, and the section on what a single system does not fix is the longest one here.

Short answer

One system puts HR, payroll and project work on a single employee record, so hours, billing and pay all come off the same entries instead of being re-keyed between tools. Running them separately leaves the same person in two places, logged hours that never reconcile to a pay run, and a project cost report showing a billing rate rather than what that person actually costs. What one system does not fix is the costing: a billing rate is not a loaded cost, and closing that gap is arithmetic you still do yourself.

It is rarely a decision. It accumulates. HR software arrives because payroll has to happen; a project tool arrives because delivery has to happen; the two are bought years apart by different people, each for a good reason. Nothing is wrong with either choice. The cost lives entirely at the seam between them, which is why it stays invisible for so long — no single tool owns the seam, so no single tool reports on it.

Why the split happens in the first place

The two systems answer different questions. HR software answers "what do we owe this person, and what are we obliged to do for them?" A project tool answers "is this work on time, and who is doing it?" Those are genuinely different problems, and the best tool for one is rarely the best tool for the other. Buying both is a reasonable decision, made twice.

What makes it expensive is not the tools. It is that both of them need the same three facts — who works here, how much time they spent, and what that time is worth — and neither is the authority on all three. Every failure below is a consequence of that one thing.

What actually breaks

Three failures, in the order they tend to surface. None is dramatic on any single day, which is exactly why they persist for years.

The same person, twice

A new hire is created in the HR system because payroll needs them, and again in the project tool because a manager needs to assign them work. From that moment there are two records for one person and nothing keeping them in step. A name change, a department move, a change of rate, a leaving date — each lands in one system and not the other. The leaver is the worst case: payroll stops, but the project account stays open, keeps its permissions, and keeps appearing in the resourcing view as though the person were still available.

How you know you have it

Someone can name a person who left and is still a selectable assignee. Or the two systems disagree about how many people work here, and nobody is quite sure which number to quote.

Hours that reconcile to nothing

Time is recorded in the project tool because it has to be billed, and attendance is recorded in the HR system because it has to be paid. Those are two different measurements of the same week, taken for different purposes, and they will not agree. Someone then reconciles them by hand — usually in a spreadsheet, usually at month end, usually the same person every month. The reconciliation is not really the problem. The problem is that it produces a third number which lives in neither system, so next month it starts again from nothing.

How you know you have it

There is a monthly spreadsheet whose entire job is to make two systems agree, and one specific person who would be missed if they were away the week it is due.

A project cost that is not a cost

This is the expensive one, and the least visible. A project tool costs a project by multiplying logged hours by a rate held against the person or the project. That rate is almost always either the rate you bill the client or a figure derived from salary. Neither is what the hour costs you. The employer contributions sit outside the project tool entirely, because the project tool has never seen a payroll run and has no way of knowing what one contains.

How you know you have it

Your project margin report and your accounts disagree about whether a project made money, and the explanation each time is some version of "that is before overheads".

What sits on top of a UK salary, and never reaches your project tool

Worth being concrete, because this is the gap that the rate in your project tool does not contain. These are the current published figures for an employer in the United Kingdom, each read from the government page listed in full at the foot of this post.

  • Employer National Insurance. For the 2026 to 2027 tax year the employer secondary Class 1 rate is 15% for a standard category A employee, charged on earnings above the secondary threshold of £96 a week — £417 a month, or £5,000 a year.
  • It is not that rate for everyone. Several National Insurance category letters carry a 0% employer rate on earnings up to £967 a week, including apprentices under 25, employees under 21 and qualifying veterans. An assumption that every head carries the same employer charge is wrong for those people.
  • Employment Allowance. Eligible employers reduce their annual National Insurance liability by up to £10,500 for 2026 to 2027. Whether you qualify is a separate question with its own rules, so check the government guidance rather than assuming it either way.
  • Pension and benefits. Under automatic enrolment the minimum employer contribution has been 3% since April 2019, with the employee at 5% and 8% in total, and it is normally calculated on earnings between £6,240 and £50,270 a year rather than on the whole salary — so the cash amount is smaller than 8% of pay. Benefits carry a charge of their own: Class 1A National Insurance, which employers pay on expenses and benefits, is 15% for 2026 to 2027.

None of that reaches an hourly rate typed into a project tool. So a project showing a comfortable margin on rate multiplied by hours can be thinner than it looks, and one showing a small loss can be worse. How much thinner depends on your own mix of people and contracts, which is exactly why it has to be worked out rather than guessed at.

If you are hiring or running payroll in the UK specifically, the country page covers the rest of the employer obligations: HR software for the UK.

What one system actually changes

Four things, and it is worth naming which four, because "everything in one place" is a slogan rather than a mechanism. This is how it works in HRMZY. The same logic applies to any platform where the records genuinely share a database rather than being synchronised across an integration. If they are synchronised, you still have two records, and you should expect every failure above.

One employee record, not two

The person a manager assigns a task to is the same record payroll pays. There is no second account to create, no second account to disable, and no argument about which system is right when they disagree, because there is only one of them. That is the whole of it. It sounds small, and it removes an entire category of recurring work. See how employee records work.

Logged time carries a value, and the invoice comes off it

A time log is attached to a task, a project and a person, and it carries an hourly rate and a monetary value with it. Those logs can then be pulled onto an invoice — approved time that is not marked non-billable, carrying a value above zero — so what you bill a client is assembled from the same entries the work was recorded in rather than re-keyed from an export. Time that is unapproved, marked non-billable or valued at zero is left out, which is the behaviour you want but is worth knowing before you reconcile an invoice against a timesheet. See project management and time logs and invoicing.

The pay run can read the same hours

A pay run can optionally include the value of project time logged in the period, so that figure reaches payroll from the entries themselves rather than from something somebody transcribed. Be clear about what it is: a switch that is off unless you turn it on, and one that adds the value of logged time on top of the stored salary structure rather than replacing it. This is not timesheet-driven payroll. It is logged time reaching a pay run without a re-key. See payroll for what a run covers.

Leave and attendance sit beside the work

Leave approved on the HR side is visible where resourcing decisions get made, because it is the same person and the same calendar. Nobody has to remember to tell the project side that somebody is away, which is the sort of thing that is only ever remembered after it has gone wrong once. See attendance tracking for how time is captured in the first place.

What one system does not change

Read this part before you decide

A consolidation post that lists only benefits is a brochure. These are the limits, including four about our own product that we would rather not have to write.

  • It does not give you a labour-inclusive project margin. The profit figure on a project is completed client payments minus approved expenses booked against that project. The cost of the hours logged on it is not subtracted, and a pay run records its salary cost as a company expense rather than against any project, so payroll never reaches a project profit and loss. Time logs give you the hours and what they are worth; turning that into a margin is still a calculation you do yourself.
  • Employer on-costs are not in there either, for the same reason. HRMZY does not compute employer National Insurance or pension contributions and fold them into a project margin. It does track employer contributions against benefit plans, which is a different thing and should not be read as this one. If you need a fully loaded cost per hour, that arithmetic still happens outside the system.
  • It does not merge your two clocks. Attendance and project time stay two separate records, taken for two different purposes, and nothing reconciles one against the other. You get one employee record and one place to look, which removes the re-keying. You do not get a single number for the week that payroll and billing both agree on. If that monthly reconciliation is the thing actually costing you, price the move on the other benefits and treat this one as still open.
  • Which rate values an hour depends on whether the project is public or private, and that catches people out. On a public project the rate is read from the employee record each time a log is saved, so a raise reaches new logs straight away. On a private project it is the rate stored against that person on that project, and several of the ways somebody gets added to a project leave it unset — time logged against an unset rate is valued at zero. So on a private project, set the member rates when you set up the project rather than when you first look at the numbers. Either way, hours already logged keep the rate they were saved with.
  • It does not decide your rates. The system will multiply hours by whatever rate you give it, with equal conviction whether the rate is right or wrong. Consolidation removes the transcription errors; it does not supply the judgement.
  • It does not make a bad estimate good. A project quoted at half the hours it needs will now be visibly, accurately and promptly unprofitable. That is an improvement on finding out in the year-end accounts, but it is not a rescue.
  • Moving is real work. Two systems leave you with two sets of history, two sets of permissions and two sets of habits. Budget for the migration honestly, and expect the first month to be slower rather than faster.

Who gains most, and who gains least

The gain is largest where the same hour has to be both paid and billed. An agency, a consultancy, a studio, a software house — anywhere a person's time leaves the building as an invoice — has the whole of this problem. One system takes the re-keying out of it: the hours, the invoice and the pay run all come off entries somebody made once. It does not take out the reconciliation itself — attendance and project time stay two separate records, as the limits above set out.

A company whose projects are entirely internal gains considerably less. If nobody bills a client for an hour, there is no invoice to reconcile a timesheet against, and the benefit narrows to the single employee record and the shared calendar. Both are worth having. Neither is worth a migration on its own. Be honest about which of the two you are before you price anything.

There is a middle case worth naming: a company whose payroll is run by an accountant or a bureau. The employee-record and time-tracking arguments still apply in full, but the payroll one does not, because the pay run is not happening in your software either way. That does not rule consolidation out. It means one of the three arguments is not yours, and you should discount it when you do the sums.

Four questions that settle it

These are not a feature comparison. They tell you whether you actually have the problem, so answer them about last month rather than about how things are supposed to work.

  1. Did anyone type the same person's details into a second system? If yes, you have the duplicate-record cost, and it recurs with every hire and every leaver for as long as the arrangement lasts.
  2. Did anyone reconcile hours between two systems by hand? If yes, write down who, and how long it took. That is a recurring monthly cost with a name attached to it.
  3. Can you say what a given project cost, without building a spreadsheet? If not, you do not have a project cost figure. You have a billing figure that is being read as one.
  4. Did a leaver keep access to anything after their last day? That is the duplicate record turning up as a security question rather than an admin one.

Three or four yeses, and the seam is costing you real time every month and probably some money you cannot see. Two, and it is worth pricing but it is not urgent — fix the one that recurs most often first. One or none, and the honest answer is that your current arrangement is working: leave it alone and spend the budget on something that is not.

The short version

Two systems is not a mistake. It is a reasonable decision made twice, and it works right up until the same facts have to be true in both places. When that starts costing a monthly reconciliation and a project cost you cannot trust, one system is worth pricing. When it does not — internal-only projects, payroll handled elsewhere, nobody re-keying anything — it is not, and you should say so. Either way, the arithmetic that decides it is about your own month, not about anybody's feature list.

Sources

Every statutory figure above was read from the official page linked beside it. Nothing here is estimated, remembered or taken from a secondary summary. Oldest reading on this page: 12 September 2026.

Statutory figures on this page link to the official source and were verified on 12 September 2026. Employment law changes — this is general information, not legal advice, and it is not a substitute for professional guidance on your own obligations.

One Database

HR, Payroll and Projects On One Record

One employee record across HR, attendance, projects, time logs and invoicing — so hours, pay and billing all come off the same entries.

  • One employee record, not two
  • Time logs carry a rate and a value
  • Invoices built from logged time
  • Pay runs can read the same hours
See every module →

A flat monthly fee per workspace, not a charge per employee

Common Questions

Frequently Asked Questions

Yes, provided the employee record is genuinely shared rather than synchronised between two products. In HRMZY the person a manager assigns a task to is the same record payroll pays, a time log carries an hourly rate and a monetary value, those logs can be attached to an invoice, and a pay run can optionally include the value of project time logged in the period.

Three things: the same person exists as two records that drift apart with every change, hours recorded for billing never reconcile with attendance recorded for pay, and project cost gets calculated from a billing rate rather than from what the person actually costs the employer.

Usually not, and it is worth checking rather than assuming. A project tool multiplies logged hours by a rate held against the person or the project, and that rate is normally the client billing rate or a figure derived from salary. Employer contributions sit outside it. HRMZY does not fold employer National Insurance or pension contributions into a project margin either, so that arithmetic still happens outside the system.

On GOV.UK figures for 2026 to 2027, a UK employer pays secondary Class 1 National Insurance at 15% on earnings above the secondary threshold of £96 a week, plus a minimum pension contribution of 3% on qualifying earnings under automatic enrolment. Several National Insurance category letters carry a 0% employer rate on earnings up to £967 a week, and eligible employers reduce their annual liability by up to £10,500 for that year through Employment Allowance.

A company whose projects are entirely internal. If nobody bills a client for an hour there is no invoice to reconcile a timesheet against, so the gain narrows to the single employee record and the shared calendar. A company whose payroll is run by an accountant or a bureau also loses one of the three arguments, because the pay run is not happening in its own software either way.

Next steps Projects and time tracking in HRMZY → How payroll runs →