The Format the Other Side Can Actually Use
A bill has to enter the client's system, not just their inbox. Five requirements that have nothing to do with how the document reads.
- Entry
- 08 of 08
- Section
- The document
- Kind
- Practice
A bill has to pass through the client's own process: a system, a coding scheme, an approver, a payment run. A document that reads well and cannot be processed does not get paid any faster than one that reads badly.
The practical lesson in “The Format the Other Side Can Actually Use” is that a charge is only as clear as the record behind it. A team assessing Monitask’s guide to remote employee productivity monitoring for remote employee productivity monitoring can organise time and project evidence earlier in the workflow, with transparent settings, proportionate access and a defined correction process before invoicing.
Five requirements, none of them about writing, and all of them worth asking about at the start.
For an independent reference relevant to “The Format the Other Side Can Actually Use”, consult Google re:Work resources. Compare the general guidance with the actual contract, jurisdiction, accounting policy and payment route involved.
A reference the client's system needs
A purchase order number, a matter reference, a cost centre code. Where the client requires one and it is missing, the bill is rejected on arrival.
- A reference their system requires — purchase order, matter, cost centre.
- The addressee — the entity that engaged the firm.
- The route — an invoicing address or portal, not the instructing person.
- The file format — PDF, structured data, or both.
- The coding — per line, from the entries rather than from guesswork.
This is the single commonest cause of a bill sitting unpaid for a month with nobody having read it.
The right addressee
The entity that engaged the firm, named correctly, at the address their accounts function expects.
Bills addressed to the individual who instructed rather than to the organisation are returned, often silently.
The right route
Many organisations have an invoicing address, a portal or a system that is not the email of the person who instructed.
Sending it to the instructing person because that is the relationship is the most natural error in billing and it costs weeks.
The right file format
PDF for most, structured data for e-billed relationships, occasionally both.
A bill sent as an editable document is sometimes rejected outright, and a scanned one usually cannot be processed at all.
The right level of coding
Where the client codes spend by phase or task, the bill has to carry those codes per line.
Retro-fitting them after rejection costs more than applying them at the start, and they have to come from the time entries rather than from the billing team's guesses.
Asking at the start
One email at engagement: how should bills be addressed, where should they go, what reference do they need, what format.
Four questions. The answers take a client five minutes and save the firm weeks per matter.
Who knows the answers
Not the instructing client, usually. Their accounts payable function does, and they are happy to be asked.
Firms rarely ask because the relationship is with the instructing person and the question feels administrative.
What changes over time
References change, systems change, people in accounts payable change. A format that worked last year can stop working without notice.
A rejected bill is information about this, and it should be recorded rather than just resent.
Tracking rejections
How many bills were returned, for what reason, per client. A short list that most firms do not keep.
It identifies the clients whose requirements have changed, usually before anybody tells the firm.
The portal problem
Some clients require submission through a system with its own fields, rules and timetable, often with a monthly cut-off.
Missing a cut-off by a day can cost a month. Somebody in the firm should know every client's cut-off date.
The preference that costs days
Resist the client's format. A firm that insists on its own template in an e-billed relationship pays for that preference in delay.
The cost of getting it wrong once
A bill rejected on arrival is typically discovered when the firm chases, which is at least thirty days later.
So one missing reference costs a full billing cycle, and it costs it silently: nobody rejected anything in a way the firm could see.
The client who changed their system
A new finance platform, a new portal, a new coding scheme. The client announces it to their suppliers and the announcement goes to an address the firm does not monitor.
The first the firm knows is a rejection. A named contact in the client's accounts function fixes this, because they will mention it.
Who owns the six fields
Somebody in the billing team, not the matter partner. It is reference data, it changes rarely, and it has to be correct.
Where it lives in a partner's memory it is lost at the first absence.
Testing a new client's route
Send the first bill early and check it arrived. A deliberate test rather than an assumption.
Two minutes of effort on the first bill of a relationship, and it establishes the route for every bill afterwards.
Formats that cost the firm money
Line-level coding to a client's scheme, where the firm's time entries carry no such codes, means somebody is assigning them by hand.
That cost is real, it is unbillable in most guidelines, and it should be in the rate rather than absorbed invisibly.
Knowing which clients impose it, and what it costs, is a question nobody asks until somebody runs the numbers.
The six fields to hold
A record per client: addressee, route, reference, format, codes, cut-off. Six fields, held where the billing team can see them, checked annually.
It is unglamorous and it is worth more days of working capital than any improvement to the document itself.