Intercompany charges from recorded hours

Two or more e.g., one entrepreneur, and at the end of each quarter an employee who puts the hours registrations next to each other to find out who has worked for who. We see that more often than you would think in companies that work with a holding company and one or more working companies, or just with a few e.g. helping each other on the payroll. Employees one day work with the other, a mechanic of the technology leg is doing a job for the rental leg, a marketer on the holding company’s payroll makes content for the subsidiary. All these hours have to be taxed somewhere. If you do not, then the financial statements are incorrect and you risk checking the relevance of the relationship between them.

The problem: Find out who owes what to whom

In practice this happens at the end of the quarter, sometimes only at the end of the year closure. Someone, often the director himself or the accountant, goes back to the time registration and tries to reconstruct the hours for which e.g. were made. That’s work that no one is waiting for and that happens months later, when no one remembers exactly whether that Tuesday in March was for one or the other e.g. the result is an estimate that is about right, a credit invoice that is made with retroactive effect, and sometimes an accountant who asks for a justification that is not there. The amount itself is not the biggest problem, which is eventually corrected. The problem is that the tax is made afterward instead of following what actually happened.

Why existing software doesn’t solve this

Accounting packages are good at processing an invoice as soon as it is there. They are not good at indicating that an invoice should have been created. Hours registration tools keep track of who has worked when, but know nothing of the bv structure behind it and of the question of who needs to charge to whom. You can create a project or cost location by e.g., but then the problem just shifts: someone still has to manually add up those cost places, translate to an internal rate and make an invoice of it.

We often see this kind of administration on Excel run: a tab per e.g. combination, updated manually each quarter by someone who knows exactly how it works, and who consequently cannot take a holiday during the quarter closure. Once that person is sick or leaves, the overload stops until someone else has understood the spreadsheet.

What we built: AdComPro

For this problem we have AdComPro The starting point is simple: an employee will book his hours on a project or job, as he does anyway. Behind that booking is fixed for which one the work is done and on which payroll the employee is on. Once these two do not match, the system recognizes that there is intercompany work and automatically counts those hours in the transfer between those e.g.

At the end of the month, instead of the quarter, the transit charge is ready: who has worked for who, how many hours, at which internal rate, and what the outstanding intercompany invoice between those e.g.s becomes. No reconstruction afterwards, no tab per e.g. combination, no dependency on one person who gets the spreadsheet. The invoice follows the hours, not the other way around. What remains, consciously, is a check moment: someone assesses the draft invoice before it enters the accounts. A system that loads blindly without anyone looking at, simply yields a wrong amount as a manual calculation sum, only faster.

We have also built the same principle for companies that work in multiple currencies: a project where hours or costs arrive in different coins, there has the same well-niet-discussion as the e.g. tax, only then on the rate instead of the hour. That is why we fix the exchange rate at the time the project is created, instead of everyone sticking their own rate on it at the time of billing. Thus, the comparison between booked hours and the final amount remains true, even months later.

This is typically a case for custom software: The problem is too specific for a ready-made accounting package and too important to run on a spreadsheet that is only understood by one person.

This doesn’t solve why a company consists of multiple bvs, and it doesn’t automatically make up for the tax side of through tax: a business internal rate remains something that your accountant needs to look at. What it does do is to remove the calculation from the people who are currently working on it manually every quarter, and the moment when an error is visible from the year closure to the month in which it arises. For the accountant, this essentially saves time: instead of following a series of reconstructions once a year, he gets twelve monthly taxes that already come in substantiated.