If you're in Finance, you've probably heard the buzz around ASC 606 — but the accounting question Ledger actually answers lives in a companion standard, ASC 340-40 (contract acquisition costs).
606 governs when you recognize revenue; 340-40 governs whether and how you capitalize and amortize the sales commissions you paid to get that revenue. Because the two standards were issued together, "606" has become shorthand people use for the whole topic — but Ledger's entire purpose is the 340-40 question: should this commission cost be capitalized and amortized over time, or expensed immediately?
That distinction matters because it also tells you whether Ledger is relevant to your business at all:
If you pay sales commissions that could plausibly qualify for capitalization (i.e., they're incremental costs of obtaining a contract), Ledger is built for you — whether your motivation is 340-40 compliance, ASC 606-adjacent reporting, or simply wanting a clean, auditable expense schedule.
If your company expenses all commissions as incurred — common for smaller companies, or where the dollar amounts are immaterial — there's nothing in Ledger you need. Every part of Ledger (the recognition workflow, component-level logic, amortization schedules) is built around the capitalize-vs-expense decision, not general-purpose expense tracking.
With Ledger, QuotaPath supports the capitalization process end to end by:
Collecting all the commission data you need to evaluate and track for capitalization purposes
Creating expense schedules, either by amortizing on a straight-line basis or recognizing immediately
Viewing Recognized records and where they fall on the calendar year
Exporting Recognized records to a waterfall report to support journal entries and upload into your accounting software
Let's walk through it.
Important: Ledger is only available for QuotaPath Growth and Premium workspaces. Only Admins have access to Ledger.
Recognizing expenses
Once earnings have been approved for your team, they'll be listed in the Unrecognized tab of the Ledger page.
Use filters on the Unrecognized tab to help streamline your process:
Components, which is how we think about "categories of revenue" as it applies to categories of expense. It's possible the commissions in each component will spread out over the same period of time.
Time period. Typically, users look at the previous month or quarter.
Tip: You can also export all Unrecognized expenses, which some companies report on.
Select all, or recognize one deal at a time, and the amount will be broken down by component.
Choosing how to recognize
You can choose to recognize the balance either immediately or on a straight-line amortization basis.
Immediate recognition expenses the full amount in a single period.
Amortization spreads the expense over multiple periods — in QuotaPath, recognizing commissions over a set term to match the life of the contract that generated them.
Tip: The most common approach to amortization is to spread the cost over the average customer life. If your average customer life is 24 months, you'd typically amortize over that period. If a deal has a term of less than 12 months, it's common to recognize immediately.
Choose to prorate daily or monthly, and add additional costs (sometimes called "fringe" benefits), such as 401(k) or insurance.
If you have mapped the additional fields, Term Start Date and Term Length, to the data in your data source, you will be able to use these deal fields in the recognition process to dynamically recognize on the correct schedule based on each individual deals date and length. For more on adding additional fields, view this article.
A current limitation to know: when you recognize from the Unrecognized tab — whether one record at a time or in bulk — Ledger applies recognition to the full outstanding balance of each record. There's currently no way to recognize a partial amount or to recognize only the "remaining balance" of a record that's already partway through a schedule elsewhere. Keep this in mind if you're bringing historical or partially-recognized balances into Ledger (see the onboarding scenario below).
Once you've set your recognition schedule, the deals will show up in the Resolved tab, along with a graph showing the accumulation of expenses and where they land on the calendar year.
You can also export your expenses for audit-ready reports. This report aggregates expenses and the days on which they fall, and you can upload it directly into your accounting software.
If a deal's close date changes after recognition
Ledger stamps every recognition row with the deal's close date at the moment you recognize it. If a deal's close date is later changed — perhaps a deal originally closed/won is moved to closed/lost with a new close date — Ledger creates a new record reflecting that updated close date and lists it in the Unrecognized tab as awaiting recognition.
This can look like a real, unrecognized balance, but in most cases it isn't one. If you already recognized both the original (positive) earnings amount and the reversal (negative) amount for that deal when it moved to closed/lost, those two entries net to $0 for the deal — the Recognized tab, the Recognized export, and the roll-forward amortization line all remain accurate.
What may be overstated is only the Unrecognized tab and its "Total Unrecognized" visual tile, because their date filter is keyed to the close date stamped on each row. A filter that covers only the new (post-change) close date will surface the reversal row without the original earnings row that offsets it, making it look like there's an outstanding balance when there isn't.
To see the true, current state of a deal, set your Unrecognized tab date filter to All time, or to any range that spans both the original close date and the updated close date — the phantom row will likely disappear once both dates are in view. The deal-details page is not affected by this, since it always queries all-time.
This is a known behavior any time a deal's close date changes after its earnings have already been recognized, and there's currently no automatic fix for it.
Do not recognize these balances from the Unrecognized tab. Recognizing a phantom row creates a third set of entries for the deal, on top of the two that already net to zero, and will overstate your actual expense.
If you spot Unrecognized balances that you believe are phantom rows like this, reach out to your Customer Success contact or our live Support chat — QuotaPath may be able to remove the affected records manually.
Onboarding Ledger mid-stream: aligning historical balances
A common situation: Your company has been amortizing (or fully expensing) commissions outside of QuotaPath, and now you want to bring that history into Ledger without double-counting or losing your existing schedule.
Because Ledger can only recognize the full outstanding balance of a record — not a partial amount — you can't simply "catch up" a record from the point it's already reached elsewhere. Here's how to handle the most common versions of this scenario:
If a commission has already been fully amortized outside of Ledger, and you want to reflect that without a lump-sum hit today:
Use straight-line amortization with the original start date and full contract term (for example, a 36-month term starting on the original commission date). This spreads the full amount across historical months in the Ledger export, rather than expensing it all in the current period. Before relying on this for closed accounting periods, check that the monthly breakdown in the export matches what you already booked in your general ledger — if those periods are closed, you may still need manual adjustments (see below).
If a commission is partway through an external amortization schedule and you want Ledger to pick up only the remaining balance:
There's no first-class workflow for this today. Two practical options:
Use a manual ledger entry to schedule just the remaining balance over the remaining months. Note that this approach won't automatically clear the associated deal's record in the Unrecognized tab, since that record still reflects the full original balance.
Recognize the deal for its full balance using a past start date and the full original term, then adjust the already-booked months in your exported report so the numbers tie back to what's already in your GL.
If accounting periods are already closed:
Don't rely on backdated recognition to true up closed books. Instead, use a manual ledger entry in the current open period, or make the adjustment directly in your exported report offline.
If you're unsure which approach fits your situation, your Customer Success or Support contact can help you think through the right method before you start recognizing balances in bulk.
*The materials in this article are for informational purposes only and do not constitute accounting or tax advice. Persons receiving information through this article should not act or rely upon this information without consulting their own accountants or tax advisors.