Skills / Reconciliation and close

Prepaid Amortization Schedule

A prepaid schedule rots the same way a fixed asset register does: it's rolled forward every close, rarely rebuilt, and whatever was wrong last month is still wrong this month plus whatever broke since. Three failures account for most of what this tie-out finds: an item whose service period already ended but still carries a balance, a beginning balance that doesn't agree to what was actually closed last period, and an item amortizing on the wrong cadence against what its own cost, start date, and end date actually require. None of these show up by reading the amortization expense line. They show up in a rollforward and a recomputation, which is why this skill runs both before proposing anything.

What it does

Prepaid amortization here builds or verifies a schedule, recomputes each item's expected amortization using its own cost, service start date, service end date, and convention, whole-month or daily, then ties the result to two places at once: the prior period as it actually closed, and the general ledger as it stands today. No clean workpaper comes out unless the schedule's rollforward foots, the beginning balance agrees to the prior period, the ending balance and current-period amortization agree to the GL, no item has amortized past its own cost, and the recomputation agrees to what the schedule states. Anywhere those checks disagree, the gap becomes a proposed catch-up, reversal, or first-time entry, with the reason stated on the line, not a number adjusted quietly into the schedule.

The one rule it can't skip

It never decides whether a payment belongs on the prepaid schedule at all. Whether something qualifies for current deduction or has to be capitalized and amortized turns on the 12-month rule and the entity's own capitalization policy threshold, and both of those are the kind of thing that changes and shouldn't come from a tool's memory. This skill assumes every item already on the schedule was properly capitalized and checks only whether the arithmetic of amortizing it is right. Where that assumption matters, the workpaper says so directly and routes the capitalization question to whoever signs the schedule, rather than quietly answering it.

How the recomputation actually runs

Every item amortizes against its own cost, service start date, service end date, and stated convention, whole-month (the common prepaid convention, even counted by calendar month) or daily (prorated by exact days). The expected cumulative amortization through the period end is computed from scratch, then netted against what the schedule already shows as amortized through the prior period. What's left over is the proposed entry: the ordinary monthly amount for an item that's current, the full catch-up for one that fell behind in an earlier period, or a reversal for one that ran ahead. An item missing its start date, end date, or cost becomes a visible exception excluded from the recomputation. It's never zeroed out or carried forward as if the gap weren't there.

What it won't do

It won't judge whether an unmatched or stale balance is really a timing issue, a missed reversal, or a genuine error behind the scenes; it states the finding and the preparer confirms the cause. It won't reconcile a book schedule to a tax schedule and call the difference wrong when the two are legitimately different, for example when the 12-month rule shortens the tax life but book amortizes over the full service period. And it won't book anything: every catch-up, reversal, or new-item entry lands in a batch for a Controller or preparer to approve or reject line by line, the same discipline the accrual-proposals skill applies to accrual entries.

Inputs and output

InputsPrepaid schedule or invoice list with each item's cost, service start and end dates, convention, and cumulative amortization through the prior period; prior-period ending balances as actually closed; GL or trial balance figures for the prepaid account and current-period amortization expense; book and tax schedules separately where they differ
OutputA tie-out workpaper with the rollforward, item-level detail and exceptions, and proposed catch-up, reversal, or first-time journal entries for every gap between the recomputation and what's currently on the schedule
Who it's forStaff accountants and Controllers who keep the prepaid schedule and tie it to the ledger every close, and whoever reviews the proposed entries before they post

Adopt's agents carry your prepaid schedule forward in the files you already keep it in, pull the invoice or contract that justifies each entry and attach it, and draft the catch-up or reversing entry coded the way your team already codes it. Nothing posts until a reviewer approves it. Sign up free, or book a pilot to run it against the prepaid account that never quite agrees to the ledger.