Time entry descriptions
for invoices
Descriptions clients don't push back on. Write multi-line descriptions on every time entry. They flow onto the Xero invoice as line items, word for word. The proof of work is already there.
Free plan. No credit card.
Audited the checkout flow and identified a session-token expiry edge case affecting about 3% of users.
Patched the token refresh logic, added a regression test, and deployed to staging for QA. Production rollout scheduled for tomorrow.
Audited the checkout flow and identified a session-token expiry edge case affecting about 3% of users.
Patched the token refresh logic, added a regression test, and deployed to staging for QA. Production rollout scheduled for tomorrow.
Why most time entry descriptions are wasted
Most time trackers were built for the people doing the tracking, not the clients receiving the invoice. The description field is short. It accepts one line. It auto-collapses on the invoice.
So people write three words. "Acme work." "Bug fix." "Meeting." Then on invoice day someone has to rewrite all of it into Xero by hand to make it look professional, retroactively, from memory.
Hour Cap inverts that. The description field is generous, multi-line, written for the client. When the time entry becomes an invoice line, the description is already there, in full, with the line breaks preserved.
A field built for the person paying the bill
Room to say what happened, and control over how much of it the client sees.
Multi-line, paragraph-style descriptions
Write what actually happened. Two sentences, three short paragraphs, whatever fits. The field does not crop and the invoice does not compress.
- Full multi-line descriptions per entry
- Line breaks preserved on the Xero invoice line
- No character limits, no compressed snippets
"Acme work"
Tells the client nothing. Looks lazy. Triggers questions.
"Checkout bug fix"
Better. Says what, not why or what changed. Client still might ask.
Fixed checkout error caused by stale session tokens. Added regression test. Deployed to staging; production rollout tomorrow.
Outcome first. Enough detail to identify. The client knows what they paid for.
Group line items the way each client expects
Some clients want every entry visible. Others want a clean per-project summary. Pick the default that suits most of your clients and override per invoice for the rest.
- One line per entry for full detail
- One line per project for a tidy summary
- One line per date for a daily breakdown
- One line per team member for staffing visibility
Override per invoice when the client wants something different.
Sometimes the description is already written
The hardest descriptions to write are the ones for work that arrived as a request. A week later you remember answering something for Acme, but not what they asked or what you told them.
When time is logged against a support thread, the request and the reply are both attached to the entry. What goes on the invoice is a summary of something already on the record.
- Time logged from the conversation keeps its link to the thread
- The client's own wording is there when you write the line
- Descriptions stop being reconstructions at month end
Morning. Two customers rang this week to say their Amex card bounced at checkout. Visa goes through fine. Can someone take a look before the weekend sale?
Hi Priya, found it. Amex was failing the address check on the new gateway rules. Fixed and tested both cards this morning, so you are clear for the sale.
Three rules that make the difference
None of them take longer than the sentence they replace.
-
Now
Write during, not after
Two sentences while the context is still warm. By Friday, Monday blurs. By the 30th, half of it is reconstruction and it reads like it.
-
Outcome
Lead with what changed for them
What changed for the client, before what you did to change it. Plain language, and acronyms only where the client uses them themselves.
-
Trust
The description is the invoice line
It goes to Xero verbatim, line breaks and all. Once you believe that, there is no rewrite at month end and no reason to write for yourself instead of the client.
What changes when the description is the invoice line
Common questions
What should I write on a time entry description?
Write what the client needs to read on the invoice, not what you would write to yourself. Lead with the outcome (what changed), include enough context to identify the work, and skip jargon the client does not share. "Fixed checkout error caused by stale session token; added regression test" beats "Bug fix" every time.
How long should a time entry description be?
Long enough that the client can tell what the work was. Two or three sentences for a typical entry. Several short paragraphs for a long session covering multiple distinct tasks. Hour Cap supports multi-line descriptions specifically because one-line fields force you to leave detail out.
Do time entry descriptions show up on the invoice?
In Hour Cap, yes. When you push a time entry to Xero, the description becomes the invoice line item description verbatim, including line breaks. Most other time trackers compress descriptions or only export the title, which is why people end up rewriting line items in Xero.
What should I write for time spent answering a client email?
You often do not have to write much, because the thread already says it. With the Customer Support Inbox add-on the time is logged against the conversation, so what the client asked for and what you answered are both attached to the entry. The description you write for the invoice is a summary of something already on the record rather than a reconstruction from memory.
Can I group multiple entries into one invoice line?
Yes. Hour Cap supports four grouping modes: one line per entry (full detail), one line per project, one line per date, and one line per team member. Pick what fits the client. Some want every entry visible; some prefer a clean per-project summary.
Should I write descriptions during or after the work?
During, or immediately after. Memory is the issue. By Friday, Monday's work blurs. By the end of the month, half the descriptions are reconstructions. Write the description while context is fresh, even just three lines, and the work-product on the invoice gets sharper.
Why I built Hour Cap
I'm Jonathan, a freelance web developer in Brisbane, Australia. After 15 years, I wanted my client work to run on one system instead of separate tools that didn't handle retainers or Xero, copy/paste errors, and time that never got invoiced. I needed one tool that handled retainers, fixed-price, and hourly projects, let me write proper multi-line descriptions, showed me what was actually profitable, and pushed straight to Xero as invoices. Nothing did all of it, so I built one. Today it is pivotal to my business: all my time tracking, invoice drafting, and profitability runs through Hour Cap, and it scales the same way for agencies and teams.
Independent and self-funded. When you email support, you reach the person who built it.
More about JonathanThe description is the invoice line
Write it once, while you still remember it. Free to start, and Xero on any paid plan.