Blog · July 3, 2026 · ~11 min read

How to track retainer hours in Toggl Track (and share a live balance URL with clients)

Toggl Track is one of the best tools for logging retainer hours. The internal side — tracking your time, filtering by client, exporting reports — works well. The gap is on the client-facing side: Toggl Track has no native way to give a retainer client a live view of how many hours remain this cycle. This guide covers both sides: how to configure Toggl for retainer work, and how to add the one step that turns your Toggl data into a bookmark your client can check themselves.

Why Toggl works well for retainer tracking internally

Toggl Track's project-and-client model maps cleanly onto retainer work. Each retainer client gets a Client record in Toggl; each type of work for that client gets a Project. When you start a timer, you tag it to the right project; Toggl accumulates the time automatically. At the end of the cycle you filter the Detailed Report to the date range of the billing cycle and export.

The features that make Toggl well-suited for retainer tracking specifically:

What Toggl Track doesn't do (and why that's a deliberate choice)

Toggl Track is designed as an internal tool. Toggl's Share functionality — the Shareable Report link — shows a time summary for a date range. It is not a retainer balance view. A shareable Toggl report shows a list of time entries or an aggregate total; it does not show a progress bar against a cap, does not know what the monthly retainer hours cap is, does not reset automatically at cycle start, and does not show "hours remaining" because Toggl doesn't model the concept of a retainer commitment.

This is not a design failure on Toggl's part. Toggl is tracking your internal time; the retainer cap is a contract term between you and your client. Those are different systems. Toggl gives you accurate time data; what you do with that data in relation to a client contract is outside Toggl's scope. The consequence is that every freelancer using Toggl for retainer work has to answer the same client question — "how many hours do we have left?" — manually, usually by running a report, doing the subtraction, and emailing the answer.

The more complete picture of why the Toggl Share link specifically doesn't bridge this gap is covered in the post on Toggl retainer report shared links — including the reasons why some consultants try to use it as a balance page and where that workflow breaks down. The short answer: the shareable link shows time consumed but not the contract cap, so the client sees hours but cannot compute remaining hours without knowing a number only you have.

Step 1: Configure Toggl Track for retainer work

Before the export step, the Toggl configuration needs to be correct or the resulting data will be hard to use. A few configuration decisions that matter specifically for retainer tracking:

Set up one Client record per retainer client

In Toggl Track's workspace, create a Client for each retainer client. This is the primary filter you'll use at export time: "show me all billable hours for Client X between these dates." If you log retainer work under a project without a client attached, you can still filter by project, but you lose the ability to aggregate across multiple projects under the same client.

For most solo freelancers, the setup is: one Client = one retainer client, one or more Projects under that client (e.g., "Strategy", "Content", "Development" as separate projects under the same client). The client-level filter at export time aggregates all the projects automatically.

Mark retainer-billable projects as billable by default

In the Project settings in Toggl, there's a "billable" toggle that sets the default billable status for new time entries under that project. For retainer projects, set this to billable by default. This means every entry you log under the project is billable unless you manually override it. You'll occasionally need to override individual entries (if you do something for the client that's clearly outside the retainer scope), but the default should be billable so you don't accidentally exclude retainer hours from the client-facing total.

Use consistent descriptions

The description field in Toggl entries becomes the work log entry visible to the client. Write descriptions at the time of logging, not retroactively, and write them as you'd want the client to read them: "SEO audit for March content calendar," not "seo stuff" or "client work." The description is not only for your records; in the retainer balance view the client will see, the description is what justifies each entry.

This matters especially for advisory and consulting retainers where the work is less tangible than a design deliverable. For context on why description quality matters more in consulting retainers than in project retainers, the post on time tracking for consultants covers the billable-vs-relationship-time distinction and how the work log entry format changes client perception.

Step 2: Export the right Toggl report

At the end of the billing cycle (or mid-cycle when you need to update the client balance), go to the Reports section of Toggl Track and run a Detailed Report. The Detailed Report is the one that includes individual entries, not the Summary Report (which aggregates time into buckets) or the Weekly Report.

Which filters to apply

Before exporting, apply these filters in the Detailed Report:

Export as CSV

Once the filters are set, export the Detailed Report as a CSV. The Toggl CSV includes columns for: user, client, project, description, start date, start time, end date, end time, duration (in decimal hours), and billable status. The file is what you'll import into HourTab to generate the client balance URL.

Note: Toggl's free plan and paid plans both include the CSV export for Detailed Reports. You do not need a paid Toggl plan to run this workflow.

Step 3: Add the client-facing layer with HourTab

With the Toggl CSV exported, the workflow to generate a client balance URL takes under a minute:

  1. Create a retainer in HourTab. Set the retainer name (your client's name or a project name), the hours cap for the cycle (e.g., 20 hours), the cycle start date, and the cycle duration (monthly, biweekly, or custom). This is the contract information that Toggl doesn't hold — the commitment size and the cycle dates.
  2. Import the Toggl CSV. Upload the exported CSV. HourTab reads the duration and description columns, sums the hours, and populates the work log with each entry from the Toggl export.
  3. Share the URL. HourTab generates a permanent public URL for the retainer. The URL shows a progress bar (hours used / hours cap), the work log entries with descriptions, and the hours remaining. The client can bookmark this URL and check it themselves at any time. No client login. No Toggl workspace access.

When you update the Toggl data mid-cycle (run the Detailed Report again, export a new CSV, re-import to HourTab), the client's URL updates automatically. The client sees the same URL; it just reflects the current hours.

The Toggl retainer tracker page has additional context on the specific Toggl-to-HourTab workflow, including how the two tools complement each other without duplicating each other's function.

Handling common Toggl retainer edge cases

Billable vs. non-billable entries for the same client

Some retainer clients also generate non-billable time — a quick call that falls outside the retainer scope, an internal planning session, a business development conversation that you don't charge for. In Toggl, log these under the client but mark them non-billable. When you apply the "Billable only" filter in the Detailed Report, they'll be excluded from the export automatically.

The risk is logging something as billable when it shouldn't be, or as non-billable when it should. Developing the habit of setting the billable flag correctly at logging time (rather than reviewing it at export time) is more reliable than auditing the billable status retroactively before each export.

Project vs. client filter: when to use each

If a client has multiple projects in Toggl, filtering at the client level aggregates all projects for that client into a single export. This is usually what you want for a retainer that covers multiple types of work for the same client.

The exception is when a client has both retainer work and project-based work tracked in the same Toggl workspace. If you're billing the same client on a monthly retainer AND on a separate fixed-price project simultaneously, you'll want to filter by the specific retainer project(s), not by the client as a whole. Otherwise the export will include time from the fixed-price project, which doesn't count against the retainer cap.

The clean solution is to use separate projects in Toggl for retainer work vs. project work for the same client, with clear project names ("Client A — Retainer" vs. "Client A — Website Redesign"), and to filter by project rather than client when exporting retainer-specific data.

Cycle alignment: when your retainer doesn't start on the first of the month

Monthly retainers don't always align with calendar months. A retainer that starts on the 15th runs from the 15th of one month to the 14th of the next. Toggl's preset date ranges (This Month, Last Month) won't match this cycle, so you'll need to use a custom date range in the Detailed Report. The custom date range picker in Toggl's report filters handles this; there's no workaround required, just manual date entry.

In HourTab, the cycle start date is configurable. Set it to the day the retainer starts (the 15th, or whatever day the contract specifies), and HourTab will use that date to calculate the cycle automatically. When you update the retainer at cycle rollover, HourTab advances the cycle start date by one month.

Team retainers: multiple people logging time in Toggl

For studios or small agencies where multiple team members log time against a shared retainer, Toggl's workspace model handles this natively: all team members log time under the same workspace, and the Detailed Report aggregates all their time under the client filter. The exported CSV includes a "User" column identifying who logged each entry.

HourTab imports the aggregated total from the CSV, which is the correct number for a retainer where all team hours count against a shared cap. If you want the client to see which team member logged which entries, the description field (which you control when logging in Toggl) is the place to add that context.

Why the client-facing layer matters

The practical effect of giving retainer clients a live balance URL changes the dynamic around the "how many hours do we have left?" question. When clients can check the balance themselves at any time, the question stops being a recurring support task for you. Clients who are approaching the cap see it coming, which gives them time to plan: prioritize the most important remaining work for the cycle, decide whether to purchase additional hours, or shift lower-priority items to the next cycle.

Mid-cycle visibility also changes how clients think about requesting work. A client who cannot see the balance tends to submit requests without any sense of the hours they're consuming. A client who sees "12 of 20 hours used" behaves more like a budget-conscious buyer: they weigh the remaining 8 hours against the requests they have outstanding and make deliberate choices about how to allocate them.

The work log entries from Toggl — the descriptions you logged in each time entry — serve as the documentation of value delivered. End-of-cycle renewal conversations that reference a work log of 20 billable hours well-documented are more straightforward than those that reference 20 hours of time blocks with generic labels. This is particularly true for advisory retainers where the deliverables are less tangible; for more on that angle, the post on management consulting retainer management covers the advisory hours justification challenge in depth.

The full Toggl retainer workflow

To summarize the complete workflow for Toggl users managing retainer clients:

  1. Configure Toggl: one Client record per retainer client, billable flag on by default for retainer projects, clear entry descriptions at log time.
  2. At update time (mid-cycle or end-of-cycle): run Detailed Report in Toggl, filter to billable entries for the client and the exact billing cycle date range, export as CSV.
  3. Import the CSV to HourTab (takes under a minute). HourTab reads the duration and description columns.
  4. The client's retainer balance URL updates to reflect the new import. The client sees the current progress bar and work log entries.
  5. At cycle rollover: advance the cycle start date in HourTab to the next cycle, run a fresh export from Toggl for the new cycle, import again.

The only change from your current Toggl workflow is the export-and-import step at update time. Everything else — how you log time in Toggl, how you run reports, how you manage projects and clients — stays the same. The retainer balance view is built from data you're already generating.

Add the client-facing layer to your Toggl workflow

Import your Toggl CSV. HourTab generates a shareable retainer balance URL in under a minute. Free for one retainer.

Related reading