Blog · June 27, 2026 · ~15 min read

Harvest retainer tracking: how to track retainer hours in Harvest (and where it falls short)

Harvest is the time tracker most freelancers already use when they start managing retainer clients. Unlike the PM tools covered earlier in this series, Harvest was built for exactly this job: logging hours against client projects, calculating costs, and producing the invoices that close out each billing cycle. Yet even Harvest — purpose-built, mature, well-designed for the freelancer’s internal tracking workflow — leaves the client-facing visibility problem open. This post covers what Harvest actually provides for retainer tracking, where the gaps are, and why its CSV export is the cleanest import source in this entire series.

This is the final post in the Pile O series, which has examined how freelancers use PM tools (Notion, ClickUp, Monday.com, Asana, Trello) and spreadsheets (Excel and Google Sheets) for retainer hour tracking. Each prior post covered the same structural problem from the tool’s specific angle: extending a project management or general-purpose tool to do something it wasn’t designed for and finding that the client-facing layer doesn’t follow. Harvest is different. It is designed for time tracking. The gap is not about extending a PM tool beyond its intended scope — it’s about one specific capability that Harvest hasn’t built: the client-facing balance view.

This post covers five areas: how freelancers arrive at Harvest for retainer tracking; what Harvest’s Project Budget feature actually does and where it stops; what the Share Report feature gives clients and where the hours-remaining calculation is missing; the client account model in Harvest (what clients see when they log into Harvest); and the two-tool setup that resolves the client-visibility gap while keeping Harvest as the authoritative time log.

Part 1: Harvest as the default retainer time tracker

Among freelancers who track billable hours seriously, Harvest has unusually high penetration. It has been the standard tool for this workflow for over a decade — used by a large proportion of independent consultants, designers, developers, and agencies who bill clients by time. The reason is simple: Harvest was built for exactly the freelancer’s workflow. Clients and projects as organizational primitives. Timer precision (start/stop, manual entry, desktop app, mobile app). Automatic invoice generation from logged hours. Integrations with common project tools. A clean reporting interface that separates time entries by client and date range with no configuration required.

For freelancers managing retainer clients, the path to Harvest is often even more direct than the PM-tool path described in earlier Pile O posts. A freelancer using Notion, Asana, or a spreadsheet to track retainer hours has typically already adopted that tool for project management first and then tried to extend it to time tracking. Harvest users often adopt the tool specifically because of the retainer billing problem: they need to track hours against a recurring client budget, generate invoices at billing cycle close, and maintain a clear record of work delivered. Harvest does all three well.

This means that many of the CSV workflows described in earlier Pile O posts are already running through Harvest. The freelancer using Asana for project management is often using Harvest as the actual time logger (Asana’s native time tracking is limited; Harvest integrates directly). The freelancer using Trello or a spreadsheet as the task record often logs their actual hours in Harvest and pulls the task list separately. The Excel freelancer who exports a CSV at billing time is often exporting from Harvest, not from the spreadsheet. Harvest is, in many retainer workflows, the hidden layer that already exists.

The result is that the question “how do I track retainer hours in Harvest” has two distinct sub-questions: one about the internal tracking workflow (which Harvest handles well) and one about client-facing visibility (which Harvest’s feature set approaches but doesn’t fully solve). The internal workflow is not the problem. The following sections examine each of Harvest’s client-facing mechanisms in detail.

Part 2: The Project Budget feature

Project Budget is the closest Harvest comes to a native retainer-balance primitive. When you create a project in Harvest, you can set a budget in hours (or in dollars, but this discussion focuses on the hours model relevant to retainer tracking). Harvest tracks hours logged against the project and compares them to the budget. When the project reaches 80% of its budget, Harvest sends an email alert to the project manager. When the project reaches 100%, it sends another.

The alert emails go to the Harvest account holder, not to the client. This is the most important structural fact about the Project Budget feature: it is an internal alert mechanism, not a client-facing visibility tool. The client receives nothing from the Project Budget feature. The 80% and 100% thresholds trigger an email to whoever manages the Harvest account. Whether that email gets forwarded, paraphrased, or ignored is the freelancer’s decision. The client’s awareness of their balance depends entirely on the freelancer taking that manual step after the alert arrives.

The second structural fact is that the budget does not auto-reset at a billing cycle date. A retainer relationship is a recurring contract: a fixed number of hours per month (or per quarter), reset at the start of each billing period. In Harvest, a “project” is not the same as a “billing period.” A project exists as long as the client relationship exists; the budget is a single number on a single project, not a cycle-aware primitive. When the billing cycle closes and a new cycle begins, the budget does not reset automatically. The freelancer must either manually reset the budget (go into project settings, change the budget number back to the retainer allocation) or create a new project for each billing cycle.

Creating a new project per billing cycle is the approach some Harvest users take for cleaner cycle boundaries. The practical cost is overhead: new project setup each month, old projects accumulating in the client’s project list, no automatic carry-forward of rollover hours, and no single “retainer with a cycle history” primitive. Manually resetting the budget on an existing project is simpler but means the 80% alert will fire at a different absolute hour count each cycle unless the budget is also updated. For standard retainers (same hours allocation each month) this is mechanical; for variable retainers (hours negotiated per cycle) it requires attention at cycle close.

What the Project Budget feature does well: it keeps the internal alert layer inside the tool you are already using for time tracking. You do not need a separate spreadsheet or calendar reminder to know when a client is approaching their allocation. The 80% alert gives advance notice; the 100% alert is the ceiling signal. For freelancers who need a passive internal tracking mechanism and are comfortable handling the client communication separately, this is a workable setup. The limitation is that it solves the internal monitoring problem and stops there.

Part 3: The Share Report feature

Harvest’s Time Reports are the primary reporting surface for retainer tracking. From the Reports tab, you can generate a detailed time report filtered by client and date range. The report presents a table of time entries: Date, Project, Task, Notes, Hours. You can filter to a single client and set the date range to the current billing period. The result is an accurate, complete time log for that client in that cycle.

The Share Report feature lets you generate a shareable URL for this report. The URL can be password-protected (the recipient must enter a password to view the report) or shared openly (anyone with the link can view it, no Harvest account required). This is the feature freelancers typically discover when they look for a way to give clients visibility into their hours without giving them a full Harvest account. The shared URL looks like a solution.

What the shared report gives the client: a table of time entries in Harvest’s interface, showing Date, Project, Task, Notes, and Hours for the selected date range. The client can see every time entry logged in the current billing period. The table is accurate and readable. For clients who want to verify specific entries (“did you log time on the strategy call on the 14th?”), the shared report answers that question directly.

What the shared report does not give the client: an hours-remaining calculation. The shared time report shows time entries. It does not show the retainer allocation. The Project Budget number lives in project settings, not in the shared report interface. The shared URL surfaces a time log table; it does not connect that table to the budget primitive and compute the balance. To know how many hours they have left, the client must do the arithmetic themselves: total the Hours column, subtract from the allocation they were told when the retainer was agreed, account for any rollover. This is not a calculation a client performs at a glance. It requires knowing the allocation, summing the table, and computing a subtraction — then interpreting whether the result is comfortable, tight, or over.

The second gap is that the shared report is a snapshot, not a live view. Harvest generates the report at the moment you click “Share.” The shared URL shows the time entries as they existed when the report was generated. It does not update as new entries are logged. If you log three more hours after sharing the link, the client’s bookmarked URL still shows the pre-logged version. To give the client an updated view, you must regenerate the report and share a new link (or re-share, depending on how Harvest’s sharing mechanism works for the specific report). This is not a live dashboard; it is a snapshot with a shareable address.

The password-protection option adds friction on the client side. A password-protected shared report requires the client to remember a password (or store it) and enter it each time they access the report. For clients who check their balance infrequently — once a week, at the start of a project phase, when they have a question — the password requirement is a deterrent. The open (no-password) share option removes that friction but creates an exposure consideration: the full time log, including task descriptions and notes, is accessible to anyone with the URL.

The practical result: the Share Report feature is the closest Harvest comes to a client-facing hours view, and it is genuinely useful for specific use cases (sending a summary at billing time, responding to a client audit question). What it does not provide is a live, self-service balance gauge — the kind the client can bookmark and check asynchronously without asking the freelancer to regenerate anything.

Part 4: The client account model

Harvest has a distinct client-facing access feature: clients can create Harvest accounts and be invited to view their projects in Harvest. This is a separate mechanism from the Share Report link — it gives the client a persistent login to the Harvest interface rather than a one-off URL. When a client logs into their Harvest account, they can see the time entries logged against their project.

The client-facing interface in Harvest is not a balance gauge. When the client logs in, they see a time log table: entries logged against their project, organized by date and task. The view is more persistent and interactive than the Share Report link (the client can filter by date range, look at historical entries, and see the log update as new entries are added). But the interface was built for billing, not for balance display. Harvest shows the client what the freelancer has billed and is in the process of billing. It does not surface the retainer allocation, compute the hours remaining, or display a cycle-aware progress indicator.

The client account model also requires the client to have a Harvest account. This is a meaningful friction point for clients who are not already Harvest users. Creating a Harvest account to view one freelancer’s time log is a friction cost — the client must sign up for a third-party service, remember another set of credentials, and navigate a time-tracking application interface to find the one view they care about (their current hours balance). Most clients in a retainer relationship are not time-tracker power users. They want to know their balance. The Harvest client account gives them much more than that, but not the specific thing they need most: a gauge they can glance at and understand in under five seconds.

By contrast, the PM tools in the earlier Pile O posts (Notion, ClickUp, Monday.com, Asana, Trello) each tried to serve the client-visibility problem through a different mechanism: Notion’s public page, ClickUp’s guest access, Monday.com’s viewer seats, Asana’s guest-level project access, Trello’s public board URL. Each ran into a version of the same problem: the tool’s client-facing mechanism exposed too much internal context, required the client to navigate a project management interface, or still didn’t present a balance gauge. Harvest’s client account is a more polished version of the same pattern. The client sees more accurate, more relevant data than a Trello public board. But they still see a time log table, not a gauge.

Part 5: Why Harvest is the best import source in this series

Each tool in the Pile O series produces a CSV export when asked. This is the connection point for the two-tool setup: the PM tool or time tracker handles the internal workflow; a retainer visibility tool handles the client-facing layer; the CSV is the bridge. The quality of the CSV — how much work is required to get it into the format the retainer visibility tool expects — varies significantly across the tools in this series.

The Harvest Detailed Report CSV is the cleanest export in the series, by a significant margin. Here is what each tool produces when you ask it for a time log:

Trello: Exports the entire board as a JSON file (all cards, all lists, all members, all attachments, all labels). This is not a time log. Reformatting it to a per-entry time log requires parsing JSON, filtering for cards with numeric custom fields, and constructing the date-hours rows manually. As discussed in the Trello retainer tracking post, this is the most indirect export path in the series.

Asana: Exports a project as CSV, but the export is a task list (one row per task, with columns for task name, assignee, due date, section, and tags). If hours are tracked as a custom numeric field on the task, that field appears as a column in the export. But the export is still a task list, not a time log — one row per task, not one row per work session. A freelancer who logs multiple work sessions against the same task gets one row with whatever the final custom field value is. As discussed in the Asana retainer tracking post, this is a structural mismatch with the time-log format a retainer tool imports.

Excel and Google Sheets: If the spreadsheet was built with one row per work session (Date, Description, Category, Hours), the export is clean and directly matches the expected import format. If the spreadsheet uses formula cells, pivot-table summaries, or monthly tabs, the export requires selecting the right range or sheet before downloading. The spreadsheet export is close to the right shape but requires the freelancer to build and maintain the right row structure from the start. As discussed in the Excel and Google Sheets retainer tracking post, this makes the spreadsheet a better import source than PM tools, but one that requires discipline in how the spreadsheet is structured.

Harvest: The Detailed Report export (Reports → Detailed → filter by client and date range → Export CSV) produces a file with one row per time entry: Date, Client, Project, Task, Notes, Hours, Billable, Invoiced. The structure is exactly what a retainer visibility tool needs: one row per work session, date column, hours column, description column. No reformatting required. No range selection required beyond the date filter and client filter you apply before exporting. Harvest already organizes data by client and project; applying those filters to the report before exporting produces a clean, scoped export in the correct format.

There is another reason the Harvest export is particularly clean: many freelancers who use PM tools for task management are already exporting Harvest CSVs for invoicing. If you use Asana or Trello or a spreadsheet as the task record and log actual time in Harvest, you are already exporting Harvest CSVs at billing time. The CSV you use to construct your invoice is the same CSV the client-facing retainer tool imports. No new export step, no new format, no reformatting. The Harvest Detailed Report is the artifact already being produced; connecting it to the client-facing layer is adding one step to a workflow that already exists.

Part 6: The two-tool setup

The two-tool setup for Harvest users is the same in structure as the setup for PM-tool users and spreadsheet users: the existing tool handles the internal time log; the client-facing retainer tool handles the balance URL. What differs for Harvest users is how little the existing workflow needs to change.

Harvest stays as the authoritative time log. All time entry continues in Harvest: timer on the desktop app, mobile app, or web interface; organized by client and project as before; Project Budget alerts continue to the account holder at 80% and 100%; invoice generation at billing cycle close proceeds normally. Harvest’s existing reporting, invoicing, and integration features are untouched. The internal tracking workflow is not disrupted by any step of this setup.

The export is the bridge. At whatever cadence makes sense for the client relationship — weekly, when approaching a threshold, at mid-cycle, or at cycle close — the freelancer exports the Harvest Detailed Report for that client and billing period (Reports → Detailed, filtered by client and date range, downloaded as CSV). This is a report Harvest users already run for invoicing. The only new step is importing the CSV into the client-facing retainer tool before generating the invoice.

HourTab handles the balance URL. After importing the Harvest CSV, HourTab produces a shareable URL with a retainer gauge (hours used / hours allocated, displayed as a percentage bar with the numeric balance prominent), a cycle reset date, and a work log the client can scroll through. The URL is permanent and bookmarkable. The client does not need a Harvest account. The client does not need to navigate any application interface. The URL shows the gauge, the balance number, and the work log immediately on load. When the freelancer imports an updated CSV, the URL reflects the update.

What this setup eliminates. The client no longer needs to be invited to Harvest, create a Harvest account, or navigate Harvest’s time-tracking interface to find their balance. They do not receive a password-protected PDF snapshot that goes stale the moment more hours are logged. They do not need to receive and interpret a forwarded budget-alert email that arrived in the freelancer’s inbox. They have a URL they bookmarked when the retainer relationship started. They check it when they have the question. The answer is there.

For Harvest users specifically, this setup has one structural advantage that doesn’t apply to PM-tool users: the cycle-reset problem is handled by the import workflow rather than by a Harvest configuration. When a new retainer cycle begins, the freelancer creates a new retainer in HourTab (or resets the existing one), sets the new hours allocation and cycle dates, and imports the Harvest export for the new cycle. The Project Budget in Harvest must still be reset manually (or a new project created), but the client-facing layer resets cleanly based on what was imported and what cycle parameters were set. The client’s bookmarked URL now shows 0 hours used against the new allocation, regardless of what the prior cycle looked like.

Part 7: Harvest and retainer contract structure

One detail that makes Harvest particularly well-suited to the two-tool setup is the alignment between Harvest’s project structure and common retainer contract terms. Retainer contracts typically define a fixed period (one month, one quarter), a fixed hour allocation for that period, rollover rules (do unused hours carry forward? do overage hours carry backward?), and a cycle reset date. Harvest’s project structure — client, project, billing type — maps closely to this. A Harvest project per client, with time tracked against tasks within that project, produces exactly the per-client per-period time log that the retainer contract references.

This alignment means that the Harvest export is not just clean in format — it is semantically correct. When you export a Harvest Detailed Report filtered to a client and a billing period, you are exporting exactly what the retainer contract covers: hours worked for this client in this period. The invoice Harvest generates at billing time is computed from the same data. The HourTab import is the same file. The numbers are consistent across the freelancer’s internal records, the client’s gauge URL, and the invoice.

Retainer contracts that specify rollover rules benefit from explicit handling at cycle close. If unused hours roll forward, the new cycle’s allocation in HourTab should include the prior cycle’s unused hours. If the contract caps rollovers (a common provision — unused hours roll up to a maximum of 50% of the standard allocation, for instance), the cap should be applied when setting the new cycle’s allocation. HourTab allows setting the allocation manually, so the rollover arithmetic can be applied at cycle-reset time and the new cycle starts with the correct allocation number regardless of what rule is in effect. For more on retainer contract structure and rollover terms, see the post on retainer contract clauses.

Part 8: The client-visibility gap in purpose-built tools

It is worth being precise about what the client-visibility gap is and why even a well-designed, purpose-built time tracker leaves it open. The gap is not a failing of Harvest specifically. It is a design-scope choice that applies to the entire category of time trackers.

Time trackers are built for the person logging time. Harvest’s users — the people Harvest is designed to serve — are freelancers and small agencies who need to log hours, track project budgets, and generate invoices. The client is a downstream recipient of the work product: they receive invoices, they get copied on project updates, they pay the bill. The client is not the user of the time tracker. The client-facing features Harvest does provide (the Share Report link, the client account) are extensions of the freelancer’s workflow into the client’s domain. They work, but they are not built around what the client actually needs: a fast, asynchronous answer to “how many hours do I have left this month?”

The interface mismatch is the same one that appears throughout this series. A Trello public board is a project management interface. An Asana project shared with a guest is a project management interface. A Harvest Detailed Report shared via link is a time-tracking reporting interface. A Google Sheet shared with “Anyone with the link” is a spreadsheet. None of these is a gauge. A gauge communicates a single value (percentage remaining) in a visual format that allows glance-based interpretation — the client sees “68% remaining” in the same motion as opening the URL, before they have read a single number. That interpretation is what the client needs at the moment they are about to send the “quick question about hours” email. The table, the board, the spreadsheet, and the share-report link all require the client to read, navigate, sum, or infer. The gauge does not.

Harvest is the best-equipped tool in the Pile O series for the internal tracking side. Its time entries are accurate (timer-precision, not manually typed into a task field); its client/project structure already scopes data correctly; its invoice generation closes the billing loop. The gap it leaves is narrow and specific: the client-facing gauge that runs alongside the internal workflow and gives the client self-service access to their balance without requiring the freelancer to regenerate anything.

Summary: what Harvest covers and what it doesn’t

For Harvest users managing retainer clients, the internal tracking story is complete. Harvest handles timer-precise hour logging, project-level budget alerts (to the account holder), time reports filtered by client and billing period, invoice generation, and a clean CSV export in the format retainer tools import. The internal workflow does not need to be supplemented.

The client-facing side has three specific gaps:

• Budget alerts go to the account holder, not the client. The client learns about their balance when the freelancer forwards an alert or sends a manual update. The client has no self-service access to the budget threshold data.
• The Share Report link produces a table, not a gauge. The shared time-entry table is accurate but does not compute hours remaining, does not auto-update as new entries are logged, and requires password entry if protected (or exposes the full time log if open). It answers “what did you work on” but not “how many hours do I have left.”
• The client account requires a Harvest account. Clients who want persistent access to their project data in Harvest must create a Harvest account. The interface they reach is a time-tracking application built for freelancers, not a balance gauge built for clients.

The two-tool setup addresses all three gaps without changing the Harvest workflow: Harvest stays as the authoritative internal time log; the client-facing retainer tool handles the balance URL; the Harvest Detailed Report CSV (which Harvest users already export for invoicing) is the bridge. The client gets a bookmarked URL with a gauge. The freelancer’s Harvest workflow is unchanged. The communication overhead — the “quick question about hours” email — goes away because the client has the answer on a URL they can check without asking.

For Harvest users specifically, the path to the two-tool setup is shorter than for any other tool in this series. The export is already clean. The data is already per-client and per-period. The workflow that produces the invoice already produces the import file. The client-facing layer is one import and one URL away from the workflow you are already running.