One of the things we notice when talking to customers are the differences that exist between the US and the UK. In America technology companies generally bill time in hours while in the UK day rates are more common, though in both cases not exclusively so. I’m not sure why this is, possibly in the US, developers are (like engineers) viewed as technicians and so invoiced hourly, I don’t know.
But these small differences do matter when it comes to building a timesheet-to-billing system, as both models need to be supported for time-and-materials work.
Hourly should be simple, you enter your time in hours and that’s what gets billed - what could be easier? Well, once you add in timers (click to start, click to pause, click to book etc.) you end up with very precise times for activities, but who wants an hourly time booking to four decimal places or an invoice for pennies (or cents)?
Daily sounds simple but can actually be quite complex. Some companies quote daily rates but behave as though they are actually hourly, charging 1.25 days for a 10 hour day, some need the system to bill one day for the same booking. Some do both depending on the client. Plus what fraction do you charge for a part day, do you bill to four decimal places of a day, or round it to a sensible fraction? If you’re capped at one day per day but book to many tasks in the same day and end up booking over your working hours, what do you show on the time backing sheet against each task; it must be consistent?
Both hourly and daily models can also apply to block hours (aka pre-pay) contracts, debiting a customer account and crystallised as part of a month-end account settlement process, contractor’s time has to be accrued and paid, vacation (and other absences) need management.
And then there’s fixed-price, work which has to be easy. Well it is unless you want to understand who in the team is earning money for you and who is not - a common request. This is not so simple for a fixed-price project because the amount earned by each time booking varies according to the progress earned and that can go backwards. How do you handle that use case?
Plus, if you have more than one legal entity, someone working for LE1 needs to be able to bill through LE2 with an automatic transfer price charge (so two billing elements) and it needs to do this without double entry and even across currencies.
So, anyone thinking about building a timesheet to billing system (after all it’s just timesheets right?) needs to consider the many niche-use cases required to exist in the real world.
HarmonyPSA supports all these requirements with ease, separating out the booking and billing elements so altering a person’s timesheet to suit a contract limit never happens. It also records how much each timesheet booking costs and earns; providing internal pivot functionality that includes custom fields so you can analyse your earned time margin against the dimension that matters to you.
Timesheets to billing isn’t rocket science, but like a lot of PSA functionality, getting it right enough to help not hinder is tricky. We’d love to discuss an issue that makes you revert to spreadsheets to generate your time-based billing so we can show you how HarmonyPSA will make the issue go away.
About the Author: Harmony Business Systems Ltd (HBS) is the company behind HarmonyPSA, the most complete cloud PSA software on the market. Developed with functionality to cater for even the most complex needs of MSPs, VARs, ISVs and Professional Services organisations, HarmonyPSA truly is the next generation of PSA systems. Follow HarmonyPSA on Twitter, LinkedIn or Website