Blog · June 26, 2026 · ~14 min read

Asana retainer tracking: how freelancers track retainer hours in Asana (and where it falls short)

Asana’s project-and-section model, custom fields, and timeline view attract freelancers who want their retainer tracking inside the same tool they use for client delivery. Its structure can be shaped into a functional internal retainer tracker. This post covers what a well-built Asana retainer setup looks like, where it holds up, and where the specific requirements of retainer tracking — especially client-facing visibility — run into limits that Asana’s architecture doesn’t resolve cleanly.

The short version: Asana works well for the internal side of retainer management — tracking work tasks against a monthly allocation, integrating time logs from tools like Harvest or Toggl, using Rules for threshold alerts, and getting a portfolio-level view of multiple retainer clients. Where it runs into friction is on the client-facing side: giving a client a clean, real-time view of hours used and hours remaining without requiring them to create an Asana account, navigate a project management task list full of internal work items, or accept a guest invitation with ongoing login requirements.

This post covers five areas: why freelancers land on Asana for retainer tracking; how to build a functional Asana retainer setup using projects, sections, custom fields, and time integrations; where the approach reaches its structural limits; the client-visibility gap that persists even with a well-configured Asana workspace; and the two-tool workflow that solves the problem without abandoning Asana.

Part 1: How freelancers arrive at Asana for retainer tracking

The path to Asana for retainer tracking follows the same pattern as Notion, ClickUp, and Monday.com: most freelancers who track retainer hours inside Asana are already using it for project management and extend it to retainer tracking because the work is already there.

Asana’s design language positions it as a team project management tool — tasks, sections, assignees, due dates, dependencies — but a solo freelancer using Asana for client work quickly discovers that the same structure that organizes project deliverables can organize retainer time entries. A project becomes a client container; a section becomes a billing cycle; a task becomes a work entry with a custom numeric field for hours logged. The model maps naturally enough that extending it to retainer tracking feels obvious rather than like a workaround.

The second factor is Asana’s custom fields layer. Unlike Trello, which has limited native numeric field support, Asana allows freelancers to add Number fields to any project and display them as columns in the List view. A project with a “Hours Logged” custom field on each task gives the freelancer a column view of all logged time for the current billing period, with a sum in the column footer. For a freelancer who wants a quick visual tally of hours consumed against a cap, this is a meaningful improvement over a text-based task description.

The third factor is Asana’s portfolio and workload views (available on Business and above). Portfolios allow a freelancer to group multiple retainer client projects into a single view and see custom field values — including numeric fields like hours remaining — in a cross-project dashboard. For a freelancer managing six to eight retainer clients simultaneously, the Portfolio view provides a cross-client hours-remaining overview that no per-project view can match. This multi-client visibility function is a genuine advantage over tools that require opening each project individually to check the balance.

The fourth factor is Asana’s native time integrations. Asana has a native integration with Harvest (a widely used time tracking tool among freelancers billing hourly retainers) that logs time from Harvest directly against Asana tasks. A freelancer who uses Harvest to track time at the task level can have those entries populate the Asana project automatically, creating a synchronized time record without double entry. The same integration is available with Toggl Track via a third-party connector. For a freelancer who was already tracking time in Harvest and managing projects in Asana, this integration makes Asana feel like the natural place to also read the retainer balance.

The result is that Asana users who manage retainer clients often end up tracking hours inside Asana by extension — not because it is the purpose-built retainer tracking tool, but because the projects, tasks, and time entries are already there and the custom fields make it functional enough for the freelancer’s internal needs.

Part 2: Building an Asana retainer setup that actually works

If you are going to track retainer hours inside Asana, there is a project structure that holds up better than an improvised task list. This section describes the setup that makes Asana retainer tracking reliable for a working freelancer.

Project structure: one project per retainer client

The foundational decision in an Asana retainer setup is the same one that appears in every PM-tool retainer approach: one project per client or one project for all retainer clients. The single-project approach (all clients as separate sections in one project) is tempting for its overview simplicity, but it makes custom field scoping awkward. Asana’s custom fields at the project level are shared across all tasks in the project — a “Hours Allocated” field set to 20 for Client A has no way to coexist with a 30-hour cap for Client B without confusing the column.

The cleaner approach is a dedicated project for each active retainer client. Within each project, sections divide the work chronologically by billing cycle. Asana’s sections function as collapsible groupings in List view — each section can represent one billing period (June 2026, July 2026, and so on). Tasks within the active section represent individual work entries for the current cycle. When the cycle closes, you complete the section’s tasks, archive or rename the section as a historical record, and create a new section for the next cycle. The active section always contains only the current period’s work.

At the project level, the custom fields that make retainer tracking functional are:

Number — Hours Logged (task level): the hours for this specific work entry. This is the primary field you update on each task when you log or complete a piece of work.
Dropdown — Category (task level): the type of work performed (Strategy, Content, Development, Admin, Calls). Useful for the monthly scope review described in the retainer scope creep management post.
Checkbox — Billable (task level): distinguishes billable retainer time from internal overhead or non-billable additions.
Date — Work Date (task level): the date the work was performed, distinct from the Asana task due date (which may be the delivery date, not the work date).

At the cycle level, the balance metadata lives best on a dedicated Summary task pinned to the top of each billing-cycle section:

Number — Hours Allocated: the contracted hours for this billing cycle.
Number — Hours Used: a manually maintained aggregate of the hours logged across all tasks in the current section.
Number — Hours Remaining: a manually calculated value (Hours Allocated minus Hours Used plus any rollover). Asana does not have a formula field type; this value requires manual entry or an external automation.
Date — Cycle Start: when the current cycle opens.
Date — Cycle End: when the current cycle closes.

The column footer in Asana’s List view displays the sum of any Number field across all tasks in the section, which means the section footer for the active cycle’s tasks automatically shows the total hours logged. This footer sum is your reference for updating the Hours Used value on the Summary task.

Why Asana doesn’t have formula fields

One of the most frequently requested Asana features is formula custom fields — the ability to define a custom field as a mathematical expression over other fields on the same task. As of 2026, Asana does not have native formula fields. The Hours Remaining value on your Summary task cannot be automatically computed from Hours Allocated minus Hours Used; you calculate it manually each time you update Hours Used.

This is a meaningful limitation compared to Monday.com (which has a Formula column type) and Notion (which has a Formula property). In Asana, maintaining the hours-remaining figure requires two manual steps every time you log work: update the Hours Used field on the Summary task to match the section footer total, then calculate and enter the new Hours Remaining value. For a freelancer logging work daily or several times per week across four to eight clients, this is an overhead that compounds.

The practical workaround for freelancers who want automation here is Asana’s Rules feature combined with an external integration like Zapier or Make. A Zapier zap triggered on Asana task creation or field update can read the section footer total via the Asana API, compute the Hours Remaining value, and write it back to the Summary task’s Hours Remaining field. This works but introduces a dependency on a third-party automation layer and requires some setup investment. For most freelancers with fewer than ten retainer clients, the manual two-step update is the lower-overhead path.

Time tracking in Asana: native and integrated

Asana’s native approach to time tracking changed significantly in recent years. Asana added a native time tracking field (actual time) to tasks on certain plan tiers, allowing freelancers to log time directly against tasks in minutes or hours without leaving Asana. The native time log accumulates against the task, and Asana displays the total in reporting views.

For freelancers who primarily track time inside a dedicated time tracking tool, Asana’s most useful integrations are the Harvest and Toggl Track connections. The Harvest integration adds a Harvest timer button to each Asana task; clicking it starts a Harvest timer pre-populated with the task name and project, and stopping the timer creates a Harvest time entry linked back to the Asana task. At the end of a billing cycle, the Harvest report for the relevant client and time range gives an authoritative time log that corresponds to Asana tasks by name and project.

This integration creates a useful division of labor: Asana manages the project structure, task context, and work log; Harvest manages the precise time tracking and produces the exportable per-cycle report. For a freelancer who already uses Harvest for invoicing and time tracking, this is the path of least resistance because neither workflow changes substantially — Asana tasks gain Harvest timer access, and Harvest entries gain Asana task association.

Portfolio view for multi-client retainer oversight

Asana’s Portfolio feature (Business plan and above) allows you to group multiple projects into a single view and display selected custom fields as columns. For a freelancer managing six or eight retainer clients, creating a “Retainer Clients” portfolio that includes each client project and surfaces the Hours Remaining and Cycle End fields gives a cross-client balance overview in one place.

The Portfolio view updates in real time as the underlying project custom fields change, so keeping the Summary task’s Hours Remaining field current keeps the Portfolio view current. For a freelancer whose primary retainer management question is “which clients are approaching their cap this month,” the Portfolio view answers it without opening each project individually.

Rules for threshold alerts

Asana’s Rules feature (available on Premium and above) allows you to define automated actions triggered by field changes, task events, or date conditions. For retainer tracking, the most useful Rule is a threshold alert: when the Hours Used field on the Summary task is updated to a value above a specified threshold (for example, 80% of the monthly allocation), a rule can post a comment on the task, send a notification, or create a separate alert task in a monitoring project.

This requires combining a Rule trigger (“when a task is updated”) with a custom field condition (“when Hours Used field value is above X”). Asana’s Rules support numeric field conditions on Business plan, making the threshold alert buildable inside Asana without an external automation tool. The alert goes to the freelancer’s Asana inbox, not to the client — which is appropriate for an internal cap-proximity warning.

A second useful Rule is a cycle-start reminder. A Rule triggered by the Cycle Start date arriving on the Summary task can post a comment or send a notification reminding you to create the new billing cycle section and scaffold the Summary task. This does not automate the section creation itself (Asana Rules cannot create sections), but the notification ensures the cycle-open workflow happens on time rather than being discovered mid-cycle.

Part 3: Structural limits of the Asana approach

The setup described above handles the freelancer’s internal needs reasonably well. The structural limits appear at two points: cycle-reset logic and client access.

The cycle-reset problem

Asana has no billing-cycle primitive. There is no concept of a recurring monthly allocation that opens on a defined date, accrues against a cap, and closes with automatic reset. The retainer tracking setup described above works around this absence with the section-per-cycle pattern: each billing period lives in its own section within the client project, and the active section defines the current period.

The limitation is that closing a cycle and opening the next one requires deliberate manual action every month. At cycle end, the workflow is: review the current section, confirm total hours logged against the section footer, update your invoice, mark the old Summary task complete, create a new section for the next cycle, add a new Summary task with the correct Hours Allocated and Cycle dates, set Hours Used and Hours Remaining to their starting values (factoring in any rollover), and archive or rename the old section. For a freelancer with two or three retainer clients on the same cycle date, this is a manageable monthly step. For a freelancer with eight clients on staggered dates, cycle-close tasks arrive continuously and the cumulative overhead is significant.

The absence of formula fields compounds this problem. Every time you log a new work entry (update Hours Logged on a task), you must also manually update Hours Used on the Summary task and recalculate Hours Remaining. There is no formula that keeps these in sync automatically. The section footer sum gives you the updated total, but transferring it to the Summary task and computing the new remainder requires two additional manual edits per logging session.

Rollover handling is entirely manual, the same as in Notion, ClickUp, and Monday.com. At cycle end, unused hours that should roll forward require you to calculate the unused balance, enter it in the new cycle’s Summary task Rollover Balance field (if you added one), and update the Hours Remaining calculation accordingly. The structural absence — no billing-cycle primitive that handles this automatically — is shared across the full category of general-purpose project management tools.

Asana’s guest access model

The more consequential structural limit for retainer tracking is Asana’s access model. Like ClickUp and Monday.com, Asana has no public-URL feature for projects or tasks. Every person who accesses an Asana project — including a client who only needs to see their hours balance — must have an Asana account.

Asana offers guest access for external collaborators. Guests are people outside your Asana organization who can be added to specific projects. On Asana’s Starter and Premium plans, the guest policy varies by billing structure — the general model is that guests do not require a paid seat as long as the total guest count stays within limits tied to the organization’s plan. On Business plans with multiple members, guest access is more flexible. But the fundamental requirement never changes: every guest must create an Asana account and accept a project invitation before they can see anything.

The invitation and account creation flow is friction-inducing. A client who receives an Asana guest invitation must: open the invitation email, click through to Asana, create an account or log in, verify their email address, and then navigate to the specific project they were invited to. The client has now invested several minutes in account setup to access a number they could have obtained from a single email reply. Most clients will complete this once. The question is whether they return.

A client who has created an Asana account and accepted the project invitation now faces a login requirement every time they want to check their retainer balance. This login threshold — open Asana, log in, navigate to the client project, find the Summary task, read the Hours Remaining field value — is high enough relative to sending an email that most clients do not make the behavior routine. The check-balance habit requires the action to be as frictionless as possible; the Asana guest model adds enough steps that clients default to the email even after completing the initial account setup.

No public URL: the hardest constraint

Asana does not have a public-URL feature. There is no mechanism — on any plan tier, including Enterprise — to generate a URL that allows a non-authenticated viewer to see a project, task, or dashboard. This places Asana in the same position as ClickUp and Monday.com on client-facing visibility: the access model is account-required, period.

Notion is the exception in this category: its Share to web feature generates a public UUID-based URL that anyone can open without a Notion account. Notion’s public share has its own trade-offs (the entire page is public, row-level access control is unavailable on public shares, and the URL is not stable or human-readable), but it at least eliminates the account-creation barrier. Asana, ClickUp, and Monday.com all require accounts. The practical implication for retainer tracking is the same across all three: there is no URL a client can bookmark and return to without going through a login.

This is a deliberate product decision in all three tools. Project management platforms store work context that organizations treat as internal — task comments, internal status notes, assignees, due dates tied to internal deadlines. Making any project publicly accessible without authentication would create security exposure that most business customers would not accept. The decision is correct for the core enterprise use case. It is the wrong default for the specific use case of a freelancer who wants a client to see a single hours balance without seeing any internal project context.

The behavioral consequence is consistent: freelancers who have built a well-configured Asana retainer tracker and given clients guest access report that the client email frequency does not decrease meaningfully. Clients who received a guest invitation and completed the account setup check their balance less often than clients who have a URL that requires no login. The login barrier is the mechanism through which the email persists.

The interface mismatch

Even for clients who do log into Asana to check their retainer balance, the interface presents the wrong information hierarchy. A well-configured Asana retainer project shows a List view of tasks with columns for date, category, hours logged, and billable status. The Hours Remaining value is on the Summary task, which appears at the top of the current-cycle section.

To read their balance, the client must: log in, navigate to the project, locate the current billing cycle section, find the Summary task, and read the Hours Remaining column value. That is four navigation steps between logging in and seeing the number they came to find. The target experience for a client checking their retainer balance is zero navigation steps — open a URL, read the number. Asana’s task list interface, even with careful project organization, cannot produce this experience because it is designed to present work items, not balance gauges.

Additionally, the client with guest access to the retainer project can see all task names, category labels, status values, and any comments the freelancer added for internal reference. A freelancer who includes internal notes (“client seems unhappy with pace, manage expectations at next call”) in task comments has inadvertently exposed those comments to the client. Asana’s guest access is project-level, not field-level. There is no mechanism to show the client only selected fields while hiding others. The information exposure surface requires careful project hygiene in any setup where client guest access is granted.

Part 4: The client-visibility gap

Understanding why the structural limits described above matter requires being precise about what client-facing retainer balance visibility actually requires. The requirements are different from what internal project management tools are designed to provide.

What a retainer balance check requires from the client

When a client wants to know their retainer balance, the behavior they are trying to perform is simple: open something and read a number. The ideal experience is: client opens a bookmarked URL, sees “14 of 20 hours used · 6 hours remain · resets July 1,” reads the work log of what has been logged so far, and closes the tab. Total time: under a minute. Zero emails sent.

This behavior requires four things: no account creation, no login, a stable bookmarkable URL, and the balance displayed as the dominant visual element rather than a column value buried in a task list. Asana meets none of these requirements. The account barrier alone is sufficient to redirect most clients to email; the interface — a project management task list with columns for assignee, due date, custom fields, and potentially internal comments — adds a navigation requirement that the client must satisfy before reaching the balance figure.

Why freelancers underestimate the friction

Freelancers who build well-configured Asana retainer setups often underestimate how much friction the client-facing side creates because the freelancer’s experience of the system is very different from the client’s. The freelancer is inside Asana all day; navigating to a client project and reading the Summary task takes ten seconds. The client is not inside Asana all day; they receive an invitation to an external tool, create an account they use for one purpose, and navigate a project management interface that shows them far more information than they wanted.

The mismatch is structural, not a fixable configuration problem. The reason clients continue to send the balance email is not that the Asana setup is poor. It is that the Asana guest model requires clients to cross a threshold — account creation, login, navigation — that the email does not. Clients who send that email once per cycle never build the Asana login habit because the login frequency is too low to make it feel routine.

The Portfolios view does not help the client

Asana’s Portfolio feature, which provides the freelancer with a cross-client hours-remaining overview, is not accessible to guests. A client invited as a guest to a single project cannot view a Portfolio that includes their project alongside others. The Portfolio view is an internal management tool for the workspace member, not a client-facing visibility mechanism.

Even if guest access to Portfolio views were available, the multi-client aggregation would be inappropriate for individual client sharing. A client does not need to see the Portfolio of all of the freelancer’s retainer clients — they need to see only their own balance. The Portfolio view is the right tool for the freelancer’s internal multi-client oversight and the wrong tool for per-client external visibility, regardless of access permissions.

Why the email persists despite a working Asana setup

Freelancers who have given clients Asana guest access and set up the retainer project correctly often report that the balance email does not stop. The behavioral pattern is the same as in Notion, ClickUp, and Monday.com: a small fraction of clients actively use the access they were given; the majority continue to send the email.

The reason is not client resistance to technology. It is that sending an email is zero friction and reading the Asana balance requires four steps. Clients make a rational comparison each time they want the balance: email requires opening an email client and typing a sentence; Asana requires a login, navigation, and locating the right value in a table column. For a client who checks once a month, the four-step process never becomes automatic, and the email remains the lower-friction path.

A client who has a bookmarked URL that loads instantly with no login — showing the balance as the first element on the screen — checks it more frequently and more proactively. The balance becomes ambient information the client can reference at any point rather than a query they must initiate with a login flow. The behavioral difference shows up in email frequency within the first two or three billing cycles after switching to a dedicated retainer URL.

Part 5: Using Asana alongside a dedicated retainer visibility tool

The practical conclusion from the structural limits above is the same as for Notion, ClickUp, and Monday.com: use Asana for what it does well and use a separate tool for the client-visibility layer. These tools are not competing — they handle different jobs in the retainer workflow.

Asana is a strong fit for the internal retainer management functions: task tracking for delivered work, project organization by billing cycle, custom fields for category and hours data, Harvest or Toggl integration for precise time logging, Rules for threshold alerts, and the Portfolio view for multi-client overview. For a freelancer who already uses Asana as their primary project management tool, keeping retainer task tracking inside Asana avoids duplication and keeps all the work context in one place.

What Asana cannot provide cleanly is the client-facing layer: a URL the client bookmarks once and returns to independently, showing the balance as a gauge rather than a column value in a task list, with no login barrier and no exposure to internal project management context. This is the gap that makes clients send the balance email even when the freelancer has a well-configured Asana retainer project.

The workflow in practice

A typical workflow for a freelancer who uses Asana for internal retainer management alongside a dedicated retainer dashboard:

Log work in Asana as usual — create a task in the current-cycle section for each piece of work, enter hours in the Hours Logged custom field, set the Category dropdown, and mark the Work Date. If you use Harvest, start the Harvest timer from the Asana task and let the integration create the time entry automatically. Asana remains the internal system of record for task context, project organization, and time log metadata.
At the end of each work session or weekly, note the section footer total for Hours Logged in the current section. This is the authoritative sum of hours consumed in the current cycle so far.
Export the current cycle’s time data as a CSV. You have two options: export the Asana project as a CSV (from the project menu → Export/Print → CSV), which produces a spreadsheet of all tasks with custom field columns including Hours Logged; or export from Harvest the time entries tagged to this client for the current billing period. Either CSV gives you a clean per-cycle work log with dates and hours.
Import the CSV into HourTab, which maps the time entries to the correct retainer, updates the client-facing URL automatically, and resets the cycle balance on the configured date. The client-facing balance is current after each import.
The client opens the bookmarked URL at any time and sees the current balance — hours used, hours remaining, cycle end date, work log in plain language. No Asana account. No login. No task list to navigate.

The Asana workspace continues to serve all the internal functions: task tracking and delivery management, Harvest time integration for precise logging, timeline and calendar views for the freelancer’s schedule, Rules for threshold alerts, and the Portfolio view for cross-client oversight. The client-facing URL is the one artifact the client receives, and it answers the balance question without requiring the client to interact with any part of the Asana workspace.

What this setup eliminates

This two-tool approach eliminates three specific problems that Asana-only retainer tracking creates:

The account and login barrier. The client never creates an Asana account. They never log in. They open a URL. This makes the balance check frictionless enough that clients do it proactively rather than emailing the freelancer to ask. The email frequency drops materially after the first billing cycle once clients have a URL they can open without logging in.

The interface mismatch. The client never sees a project management task list. The dedicated retainer dashboard shows the balance as the dominant element — a gauge with hours used and hours remaining labeled clearly, a cycle end date, and a plain-language work log below. The client reads the number immediately on page load without locating the right task, finding the right column, and interpreting it against the allocation.

The information exposure risk. The client never has access to the Asana workspace. There is no possibility of the client seeing internal task comments, status values, internal category labels, or any other project management context the freelancer included for their own reference. The client-facing dashboard shows only what was explicitly imported: the time entries and the retainer configuration. The freelancer controls exactly what the client sees.

How this fits with Harvest or Toggl already in the workflow

For freelancers who use Harvest alongside Asana, the export workflow is particularly clean. Harvest already produces per-client per-date-range CSV exports of all time entries. A Harvest report filtered to one client and the current billing period gives a clean, importable time log with exactly the fields needed: date, hours, description. There is no need to export from Asana at all — Harvest is already the authoritative time log; Asana is the task management layer. Import the Harvest CSV into HourTab and the retainer balance is current.

The same applies to Toggl Track. Toggl’s detailed report export (CSV, filtered by client and date range) produces an importable time log. A freelancer who uses the Toggl Track + Asana connection to sync Toggl entries against Asana tasks has both the task context in Asana and the clean time log in Toggl. The HourTab import uses the Toggl CSV as its source; the Asana task structure continues to serve the internal project management function.

Who this setup works for

This approach is well suited to freelancers who are already invested in Asana for project management and delivery tracking and do not want to change their internal workflow. If Asana is where your client tasks, deadlines, and project context live — and where your Harvest or Toggl time entries are already associated — there is no reason to abandon it. The client-facing retainer dashboard is an additive layer that handles the one function Asana’s architecture is not designed for: frictionless client access to a live retainer balance.

It is also suited to freelancers who have tried giving clients Asana guest access and found that clients don’t return to check their balance consistently. Guest access works in theory; the export-and-import approach works in practice because it removes the login requirement entirely and replaces the project management task list with a purpose-built balance display.

For freelancers choosing their retainer tracking workflow from scratch, the decision of whether to use Asana for internal management versus a lighter tool is a separate question from the client-visibility layer. The client-visibility layer — a public, no-login URL per retainer — applies regardless of which internal tool handles project management and time logging. The same CSV export workflow functions from Toggl, Harvest, Clockify, an Asana project export, or any tool that produces time data as CSV. The internal tool does not constrain the client-visibility choice.

HourTab is designed for the client-facing layer in this setup: CSV import from Asana exports, Harvest reports, Toggl exports, or any time-tracking CSV; one public URL per retainer that the client bookmarks once; a progress bar showing hours used and hours remaining this cycle; the work log as a dated list of entries in plain language; and automatic cycle reset on the configured date. It does not replace Asana for internal project management, task tracking, and delivery coordination — it fills the specific gap that Asana’s account-required model leaves open on the client-visibility side.

If you are currently tracking retainer hours in Asana and still receiving the balance email from clients, the issue is almost certainly not the quality of your Asana setup. It is that Asana’s guest access model requires clients to cross a friction threshold — account creation, login, project navigation, column reading — that most clients will not consistently clear. The fix is the client-facing layer, not a better Asana project configuration.