Recharging between companies in a group, without losing your month to it

In almost every group we meet, there's one person whose month partly consists of recharging shared costs to the group's companies. And beside them sits a little file that only they know how to run.

It's never on the org chart. Yet it's one of the most time-consuming and most fragile processes in the business.

Why it's always done by hand#

Because the difficulty isn't the invoice: it's the allocation key.

An example, barely simplified#

A group centrally buys a block of travel vouchers, because at volume it gets twenty to thirty percent off the public price. One group company requests a trip; vouchers are allocated to it; it has to be recharged.

Except the person traveling is employed by the holding company, and works for company A thirty percent of the time, for company B twenty percent, and for company C the rest. So the recharge has to be split three ways. And sometimes pushed down to branch level, because some companies keep a P&L per branch.

Why does no software handle intragroup recharging?#

No travel management software knows how to do that. Nor does any accounting package, because the key isn't accounting: it's organizational, and it changes when somebody changes job.

It isn't complicated. It's just exactly the same thing, every month, for every company.

"Exactly the same thing, on a loop" is the best definition there is of what should be automated.

The real cost, which is double#

The time of the person doing the recharging#

First, the time of whoever produces the internal invoices, every month, company by company.

Where does the real cost of recharging hide?#

That is the larger of the two, and the less visible.

Because the little file produces a paper invoice, or a PDF. That invoice is perfectly valid, numbered, provided for in the chart of accounts. But it has to be re-entered by hand into the receiving company's ledger. At ten companies and a few dozen lines a month, that's several working days a year — in a context where e-invoicing is precisely making this kind of flow measurable.

The cost is simple to work out:

(hours to produce + hours to re-key) × loaded hourly cost × 12

Add what can't be costed: the controller who can't trace an allocation, the discrepancy found at close, and the dependency on a single person.

The four pieces of data you need#

To automate, you need these four, and they're enough.

1. The register of companies and branches, with their accounting identifiers. The simplest, and often the dirtiest.

2. The allocation key per person, with a start date and an end date. The key point is the date: a split that changes mid-year must be recoverable as it stood in the month concerned.

3. The rechargeable event, with what links it to a person and a date: a trip, a service, a consumption.

4. The proof, where it's required. In the travel example, the boarding pass — because until the trip is proven to have happened, you don't know whether to recharge this trip, or another one.

That fourth point isn't administrative paranoia. It comes from a mishap several groups have had: vouchers allocated for a business trip, used for a family weekend. You don't put controls in place for fun; you put them in place once it has happened.

What automation looks like#

The full mechanism has five steps, and humans are involved in only two of them.

What really changes is the last line. The internal invoice is no longer produced and then re-keyed — it's produced and recorded on both sides, with its cost allocation. The person who kept the file goes from several days to a few minutes of checking.

What not to automate#

Three things, and they're always the same.

Changing an allocation key#

It must be entered by a named person, dated, and logged. It's an organizational decision, not a data point. A key that moves on its own is the surest way to make a close impossible to explain.

The exception#

There will be some: an urgent trip outside the process, a cost you decide not to recharge. The application must allow an override, on condition of a written reason. A system that accepts no exception is worked around within the month.

Chasing beyond two reminders#

The first two go out automatically. The third is a conversation between two people, and it should stay one.

How we automate recharging#

Intragroup recharging is expensive because it is done by hand, at month end, from files somebody has to reconstruct. What we install records the expense as it happens, with its allocation key already attached.

At close, the internal invoice is generated from what is already captured: no reconstruction, no allocation spreadsheet, and a verifiable trail if you are audited. See the invoicing and collection module.

Intragroup recharging: what to remember#

It isn't an accounting problem, it's an allocation key problem — and that's why no off-the-shelf package solves it.

The cost hides mostly downstream, in the re-keying on the receiving companies' side. Cost both before deciding.

And keep your allocation keys with their effective dates. It's the data that makes the rest automatable, and the only one that must stay in human hands.