Key takeaways:

• A prepaid balance is proved three ways: the tie proves the balance, the rollforward proves the movement, and the line scan proves the population. Each catches what the one before it cannot.

• Every proof depends on the independence of what it compares against. A schedule that came from the ledger cannot vouch for the ledger.

• NetSuite's Deferred Expense Rollforward report ties to the GL by construction. Oracle defines its Variance column as zero in a single-subsidiary context, so it cannot be the independent side of any proof.

• Report parameters, run time, and a completeness check belong in the workpaper, because auditors must test the accuracy and completeness of information the company produces.

  
  

Introduction

A prepaid reconciliation proves that the prepaid balance in the general ledger equals the remaining unamortized value of the company's prepayments, plus or minus supported reconciling items. It ties the schedule to the GL, rolls it forward from the prior approved period, and tests each line for a valid service period and posted amortization.

Most teams already run the first of those three tests every month. The other two are where the balance is actually proved.

Here is how the month usually goes. The preparer opens last month's prepaid workbook, adds a tab, and runs the team's monthly amortization schedule search with the period rolled forward. The export is filtered to lines with something left, the remaining balance column is footed, and the GL balance is typed next to it. The two agree, or they agree once the bill that was coded to prepaid without a template turns up. The export goes under the tab, the search results are attached, and the file moves on to accrued liabilities.

That workbook will pass most reviews. It should not. It ran one proof of three. The second locates where a difference sits; the third finds the errors that cancel each other out and never surface as a difference at all.

What a prepaid reconciliation proves

Under ASC 340-10, a prepaid expense is an amount paid to secure the use of assets or the receipt of services in a future period. The balance sheet carries it among current assets while the benefit falls due within a year or the operating cycle (ASC 210-10-45), and amortization releases it to expense as the service is delivered. The account is therefore a population of contracts, each with an amount, a start date, an end date, and a remaining balance, and a prepaid expense reconciliation has to prove the population, not just the total.

Three proofs do that.

• The balance proof. The remaining unamortized balance across every open prepaid, plus or minus the reconciling items the workpaper supports, equals the GL ending balance. This is the tie. It establishes agreement at a point in time and nothing else. It cannot say why the two sides agree.

• The movement proof. Start from the prior period's approved ending balance, add the period's additions, deduct the period's amortization, and compare the result with the GL. This is the prepaid rollforward, and its value lies entirely in where each input comes from. Opening ties to last month's signed reconciliation. Additions tie to the vendor bills and journals posted to the account. Amortization is recomputed from contract terms and the company's recognition method, straight-line across the service months unless the pattern of benefit says otherwise, rather than read from the ledger. Built that way, the rollforward exposes a manual journal posted around the schedule, a template that kept running, and a prior-period balance altered after sign-off. Built from ledger activity, it exposes none of them, because it agrees with the ledger by definition.

• The population proof. Each line is tested on its own. No negative balances. No fully amortized contracts still carrying a balance. No posting in the account without a schedule or an explained reconciling item, and no schedule line without a source transaction behind it. No line whose current-period amortization was planned and not posted. Account-level tests cannot see two errors that cancel. The line scan can.

The distinction that matters runs through all three: a proof is only as strong as the independence of the thing it compares against. A schedule that was built from the ledger, filtered to the ledger, or adjusted until it agreed with the ledger is not evidence for the ledger.

The prepaid schedule: building and maintaining the subledger

The prepaid schedule is the sub-ledger for the account, whether it lives in the ERP's amortization module, a subledger platform, or a workbook. To support the three proofs it needs, per line:

Three structural checks sit above the lines. A completeness check compares the row count and total of the imported extract against the source it was pulled from, so nothing was dropped or doubled on the way into the workbook. A population match confirms that every posting in the GL detail has a schedule line or a reconciling item that explains it, and that every schedule line traces to a posting. That is a different test from footing the two totals. And the prior period's approved workbook is an input to the current one, not a reference: the opening balance is inherited from a signed document, which is what makes the movement proof a proof.

Maintaining the schedule is a different discipline from building it, and it is where most of them decay. A line is added the day its source transaction posts to the account, whether that is a bill, a vendor credit, or a journal, not the day someone notices it. When new information changes the estimated service period, the effect is applied to the remaining months prospectively, with the original terms kept visible. Dates that were wrong on evidence available at the time are an error, and are corrected as one. A cancellation, refund, or vendor credit changes the line's remaining balance and its schedule: a full one closes the line, a partial one reduces it, and either is booked in the period it happens. Fully amortized lines leave the active population but stay in the file, so the prior period can still be re-performed. And at each quarter end the short-term and long-term split is recomputed from what each line has left. A schedule maintained this way is independent of the ledger, which is the property all three proofs depend on.

The dates are where that independence is won or lost, and the hard part is rarely the arithmetic. It is choosing which document rules when they conflict. One purchase order can cover three years of service invoiced a year at a time. A master agreement sets the relationship while a statement of work sets the period of a single service under it. An invoice may state service dates, or state nothing. No rule says the invoice always wins or the contract always wins; the company's procedure has to say which source controls each attribute, and the preparer has to stop on ambiguity rather than take whichever date makes the schedule agree. The reason that matters is that the same wrong date drives both the schedule and the amortization journal, so the two sides agree exactly while both are wrong.

Where the ERP builds the schedule, the constraints on which transactions can carry one matter. NetSuite, for example, disables amortization settings on a vendor bill line that came from a purchase order line already carrying an accrual, and a schedule only comes into existence once the bill has been approved. Those mechanics are covered in Maxima's NetSuite account reconciliation guide. For groups that run dozens of entities, the operating-model question of where the schedules should live is covered in how to automate prepaid amortization across multiple entities.

A prepaid tie-out, worked

A software company closes March. Its prepaid expenses account holds subscriptions, insurance, and service contracts, all recognized straight-line. February's approved reconciliation ended at $742,500.

During March, three bills posted to the account:

March amortization, worked out from contract terms across the whole population, comes to $76,200: $61,200 from contracts that were already open, plus $12,000 for the security platform and $3,000 for the retainer. The support contract has not started, so it contributes nothing in March.

The balance proof

The schedule, footed line by line, shows a remaining unamortized balance of $882,300 across every open contract, the three March additions included. The GL ending balance is $870,300.

The account does not tie. Good: the difference is information. The preparer now knows the ledger carries $12,000 less asset than the contracts support. The movement proof says where.

The movement proof

Opening agrees to February's signed reconciliation. Additions agree to the three bills. The whole $12,000 sits in one movement: the ledger recognized $88,200 of expense against $76,200 the contracts support, and the excess sits on one line. The security platform's scheduled $12,000 posted correctly. Then a manual journal released the same $12,000 a second time, debiting software expense and crediting prepaids with no schedule behind it.

One reversing entry brings March expense to $76,200 and the GL balance to $882,300:

The account ties, the rollforward foots to zero, and the reviewer can see both from the same page.

Now the part that a workbook built from the ledger would have skipped. Had the preparer used the ERP's own deferred expense rollforward as the schedule, the report would have shown $88,200 of expense, an ending balance of $870,300, and a variance of zero, because the report is built from what posted. The manual journal would have been inside the tie, not outside it.

The population proof

With the account tied and rolled forward, the line scan runs, comparing what posted against each line's terms. Two lines fail.

A recruiting retainer, six months from September, fully amortized in February. Its schedule had been set up as a fixed $3,000 a month with an end date one period too late. The March run generated one more $3,000 journal against a line with nothing left, and the line now shows a remaining balance of negative $3,000.

An analytics license, $36,000 annual from December, shows $3,000 of March amortization planned and not posted. Its March journal was never generated. The schedule had been held out of the February run while the bill was queried with the vendor, and nobody put it back.

The two errors cancel to the cent. The account tied at $882,300 and rolled forward to zero with both of them inside it. The corrections leave the ending balance unchanged and move $3,000 of expense from one expense account to the right one, which the flux reviewer would otherwise have been asked to explain next week:

The addition that has not started

The $54,000 support contract sits in the ledger, because the bill posted on March 20, and in the schedule, with a start date of April 1 and no amortization. A preparer who filters the sub-ledger to active schedules loses the line and finds the schedule $54,000 short of the GL. That leaves two bad options: book a reconciling item for a bill that needs none, or edit the ledger side until the numbers meet.

The line belongs in the reconciliation exactly as it is. It is a valid prepaid with a future service period, it is in both populations, and it already ties. The workpaper should count and quantify every such line and say in plain words that nothing was removed to make the account agree.

Review-ready, the March reconciliation shows a GL balance of $882,300, a supported balance of $882,300, and a rollforward variance of zero. It references one correcting entry and two line corrections by journal number, identifies $54,000 of not-yet-started additions, and gives every exception an owner, an aging, and a target clearing date.

The tie that hides a problem: agreement that proves nothing

Every accountant has seen a prepaid account that ties every month and is wrong every month. The tie survives because the two sides are not independent. Three ways that happens:

• The circular tie. The schedule is a report run from the ledger. Anything posted to the account is in it, including the manual journal that duplicated a scheduled release, the template that ran a period too long, and the reclass that landed in the wrong period. The report's ending balance equals the account balance because they are the same number viewed twice.

• The forced tie. The support contract above, dropped from a schedule filtered to amortizing lines, then chased out of the ledger side or dressed as a reconciling item. The account agrees. The population is smaller than the balance it claims to support.

• The cancelling pair. The retainer and the license above. Both account-level tests pass, the reviewer sees a clean page, and the preparer explains a variance of zero.

The defense against all three is the same. The schedule is built from contract terms and source transactions. The rollforward recomputes amortization from those terms. The line scan runs every month whether or not the account ties. A reconciliation that skips the scan when the tie is clean has handed the control to the zero. The tie is not the control.

Where prepaid reconciliations break

The three proofs exist because of the failures below. Each is listed with the test that catches it:

• Rows dropped or doubled on export. The saved search was filtered, a subsidiary was excluded, or a copy-paste duplicated a block. Caught by the completeness and population checks.

• Amortization released twice, or not at all. A manual journal repeats what the schedule already posted, or a period is skipped while a line sits on hold. Caught by the movement proof, because expected amortization comes from terms.

• A bill in the account with no template. Coded to prepaid at entry, never scheduled, never amortized. It ages into unrecorded expense. Caught by the line scan, and it needs an owner and a clearing date the month it appears, not a note.

• A schedule end date set wrong. The line keeps amortizing past zero, or stops early and strands a balance. Caught by the negative-balance and fully-amortized scans.

• Future-period lines excluded to make the account agree. Caught by counting and valuing not-yet-started additions inside the reconciliation, with a statement that none were removed.

• The quarterly short-term and long-term split not recomputed. Each line's remaining balance has to be allocated between the next year, or the operating cycle if longer, and the period after that, from its remaining recognition period. Then the reclassification journal is booked. A split carried forward from last quarter is wrong by definition. Caught by recomputing it, every quarter end, from the lines.

• The same reconciling item carried forward month after month. A timing item that trues up next period is normal. A timing item that has trued up for six months is a control failure. Caught by comparing this month's items with last month's and asking which ones are chronic.

• An unexplained movement. The account grew 40% in a month with no matching growth in additions. Caught by an analytical review inside the reconciliation, before flux, with a threshold that respects seasonality.

• A commission balance parked in prepaids. A capitalized commission that clears through a different schedule in a different period sits in the reconciling items as "timing." Caught by pointing the item at the schedule that owns it and the period it clears.

• A zero-balance account treated as no work. Nothing to reconcile can mean nothing happened, or that the amortization journals stopped. Caught by recording that the population was checked and what the open contracts imply, even when the answer is zero.

On the quarterly split, a small example, assuming a one-year operating cycle so that twelve months is the classification line. A $96,000 contract runs 24 months from January 1, amortizing $4,000 a month. At March 31, $12,000 has been amortized and $84,000 remains. The next twelve months, April through March, will consume $48,000, which is short-term. The remaining $36,000 is long-term. The reclassification journal moves $36,000 out of the current prepaid account, and it is recomputed, not rolled, at June 30.

How this works in NetSuite

With the Amortization feature enabled, NetSuite creates an amortization schedule for each vendor bill, vendor credit, or journal entry line that carries a template. The expense reaches the GL only when the period's amortization journal entries are generated from those schedules.

NetSuite also ships a report set under Reports > Financial that teams commonly use as the sub-ledger, and the reports fall into two families that should not be confused. The Amortization Forecast and Deferred/Capitalized Expense reports are built from the schedules: what each transaction plans to recognize, and the amortized and remaining balance on each schedule line. They are the schedule side, and a schedule-based extract like the one in the opening is a legitimate input to the balance proof. The Deferred Expense Rollforward is built from what posted, and the Deferred Expense Waterfall lays the planned recognition stream over the posted balance. Oracle's reports page for revenue management and amortization describes the waterfall and rollforward reports as "designed for expense reconciliation purposes" and states that their balances "tie directly to the general ledger account balances."

That sentence is the circular tie from the hidden-problem section, in Oracle's own words. Read the Deferred Expense Rollforward Summary column definitions as a controller. Beginning Balance is last period's balance sheet figure. New Transactions is the vendor bills and credits that hit the account. Expense is whatever posted to expense accounts, the system-generated amortization journals and any manual journal touching expense alike. Adjustments picks up manual journals moving deferred expense to expense. Ending Balance is this period's balance sheet figure. And Variance, in a single-subsidiary context, is zero. Not zero when the account is right. Zero.

The report is a faithful rollforward of what posted. That makes it a good place to see the account's activity and a poor independent side for any of the three proofs, because its Expense column is the ledger's expense, not the expense the contracts imply. The manual journal and the over-running template from the worked example both land in it and both tie. The Deferred Expense Waterfall is more useful as a line-level test, and two of its columns correspond to failures above. Oracle defines "Prior Unrecognized" as amounts due for recognition by period end that have not been recognized, and "Unplanned deferred expense" as amounts billed but not yet on any amortization schedule. Both columns should be zero, or explained, before the reconciliation is submitted.

Three practical notes from the same documentation. Run the rollforward with a single subsidiary selected in Subsidiary Context; in a consolidated context Oracle computes the Variance column differently, so a zero means something different on each run. The waterfall shows results regardless of role restrictions on transactions, to anyone whose role carries the Deferred Expense Reports permission, which is worth knowing when the schedule population and the GL population were pulled by different people. And run both reports after the amortization journals for the period have been generated, or the Prior Unrecognized column will show timing rather than error.

What NetSuite does not produce is the independent side. Expected amortization from contract terms, the line scan for negatives and stranded balances, the count of not-yet-started additions, the aging of unapplied bills, and the opening balance inherited from a signed prior-period workpaper all live outside the report set. For which transactions can carry a schedule at all, and what certification means once a late posting changes the balance, see the NetSuite account reconciliation guide.

Evidence an auditor can rely on

A prepaid workpaper is mostly built from reports the company ran on its own system. Auditors treat that as information produced by the entity. When they use it as evidence, PCAOB AS 1105.10 requires them to test its accuracy and completeness, or to test the controls over it, including information technology general controls where applicable, and to evaluate whether it is sufficiently precise and detailed. AU-C 500 and ISA 500 carry the equivalent requirement for audits outside the PCAOB's scope.

Every reviewer knows the moment this rule is written for. A question about a line, a pause, and a preparer saying they will go and find the support. The practical consequence for the controller: if the auditor cannot rely on controls over the ERP, the workpaper has to carry what the auditor would otherwise have to reconstruct. That means, on every tab that holds a system extract, the report or saved search identifier, the parameters it was run with, the extraction date and time, the period, the subsidiary context, and a link back to the source. A schedule pasted into a workbook with none of that is an unsupported number regardless of whether it ties.

This is also the argument for keeping the completeness check inside the reconciliation. The standard does not prescribe a procedure. The completeness check and the population match are one practical way to evidence the accuracy and completeness it requires. They are performed by the preparer, documented once, and re-performable by anyone who opens the file.

How Maxima prepares the prepaid reconciliation

Prepaid schedules, amortization journals, rollforwards, and account certification are automated to some degree by the ERP itself and by most close platforms, and several of those platforms now prepare the reconciliation with agents as well.

What separates tools is not whether they do those things but how much of the preparation they perform and whether the chain from source document to certified balance stays connected. Several tools certify an account when a template balance matches the GL. That is real work removed, and this article has spent several sections on why a match is only the first of three tests. So the question to ask of any tool, Maxima included, is what the balance being certified has already been through.

Maxima's published description of its Account Reconciliations product is short: ending balance and status are derived from the opening balance and the period's activity, uncleared items carry into the next period, and thresholds decide which variances need a person. The module can sign off automatically when the workbook balance sits within a configured tolerance of the GL, and can sign off accounts with no activity. The difference lies upstream of the module. For a prepaid account, the balance it certifies is one the agent has already taken through the movement proof and the line scan. Where Maxima also runs the prepaid subledger, with schedules prepared from contract terms, amortization posted, and the quarterly reclass automated, the schedule side is independent of the ledger by construction. The reconciliation is fed by that work rather than prepared at month end. What it looks like for a single prepaid account is a workpaper the agent builds and a human reviews.

What follows is one configuration of that workflow for a prepaid account; where a behavior is also covered by a published release note or product page, that source is named. The workflow is a written procedure on a recurring checklist task, the document a controller would hand a new hire: source data, templates, output locations, notification channel, and the gates the run may not pass until their condition is met. The sources are the ERP's prepaid amortization schedule extract for the account range, the GL balances and detail for those accounts, the company's own reconciliation procedure and its list of safeguards, and the prior period's approved workbook. That last input is the design choice that matters: the current reconciliation starts from a signed document, not a blank sheet.

Before it plans, the agent resolves ambiguity rather than working through it. When the task period and the source files disagree, it asks which close it is running and confirms the month is locked before producing a plan. Maxima's July 2026 release notes describe this: period, entity, account and source are gathered in one exchange before the work starts.

The workbook it produces has a fixed structure, which is itself a control, because it makes the March file comparable with February's. Its parts:

• A lead sheet, one row per prepaid account: GL balance, schedule total, reconciling items, reconciled balance, difference; beneath it the materiality conclusion and the completeness and population checks.

• A rollforward tab, one row per account: opening, additions, amortization, calculated ending, GL ending, and a three-way check of sub-ledger less reconciling items less GL. Every check column is expected to read zero.

• A reconciling items tab, per item: category, evidence reference, amount, days aged, owner, target clearing date, status. Beneath it, not-yet-started additions counted and valued, unapplied bills aged with an owner, and a comparison with last period's items so that a chronic "timing" item cannot hide in the carryforward.

The reconciled balance on the lead sheet carries a reference for each account, and the Account Reconciliations module reads it. The module shows the GL balance, the workbook balance, the variance, and the preparer and reviewer with their due dates, and nobody exports the sheet or uploads it.Both balances refresh on demand, so a late NetSuite posting is re-tested in the same session, and sign-off happens directly from the reconciliation list.

When the run reaches its gate, the agent posts one structured message to the team's channel. It carries the period, a link to the workbook, the per-account tie and rollforward results, the not-yet-started additions for confirmation, each reconciling item in plain English with its owner, and a request for reviewer approval. Maxima's integrations page lists Slack for capturing approvals and the discussion around them. The reviewer approves in the thread. On approval, the sign-off is written into the lead sheet with a name and date, the segregation-of-duties row is marked complete with the approval reference, and the reconciliation is finalized in the module.

A movement beyond a percentage threshold on any prepaid account is flagged inside the reconciliation, before flux, so the preparer judges it while the support is open. The threshold is a judgment, because a January insurance renewal is not an anomaly. Flux comments cite the GL lines and the calculation behind them.

For instance, Rewst reports its close shortened from 20 days to 10 after automating deferred revenue and prepaids with Maxima. It describes booking revenue and prepaids as having gone from more than ten hours of work to "two clicks and a five minute review." For how the same preparation carries into the amortization journals themselves, see Maxima's journal entry automation, and for the broader method across account types, the definitive guide to reconciliations in accounting.

What the accountant still decides

The agent prepares, tests, documents, and asks. It does not decide. Named people still own the policy on what is prepaid, the capitalization and materiality thresholds, and which source governs a date when the documents disagree. They decide whether a changed service period alters the pattern, how a chronic item is treated, which routine accounts may certify automatically and which need a named review, and whether a correcting entry is approved. The sign-off is theirs.

A prepaid account that agrees to its schedule has passed one test of three. The file is finished when each line shows what it is, why it is there, when it will leave, and who confirmed it. Done that way, next month's preparer inherits evidence instead of rebuilding it from the ledger. See how Maxima prepares prepaid reconciliation work by booking a demo, and bring the account that ties every month.

Frequently asked questions

How does a prepaid tie-out differ from a prepaid rollforward?

The tie-out compares two balances at a point in time: the remaining unamortized value per the schedule against the GL. The rollforward tests the movement between two points: opening plus additions less amortization, with each input from an independent source. An account can tie because its schedule side was taken from the ledger, and still fail a rollforward whose amortization is recomputed from terms. That failure is where doubled or missing amortization is found.

Should a prepaid whose service period starts next month be in this month's reconciliation?

Yes, if its source transaction has posted to the account. It is a prepaid whose service has not begun, nothing more. Count it, quantify it, and leave it in the population. Removing it to make the schedule agree with the ledger is a forced tie.

How do you reconcile a prepaid account with no activity?

Prove the absence. Show the opening balance, zero additions, the amortization the open contracts imply, and the ending balance, and run the line scan anyway. An account with no activity and a balance that has not moved may be an account where the amortization journals have stopped.

When are prepaid expenses reclassified between short-term and long-term?

At each reporting date, usually quarter end. For each line, the amount due for recognition within one year of the balance sheet date, or within the operating cycle if that is longer, is presented as current; whatever falls beyond that is non-current. The split is recomputed from each line's remaining recognition period, and the reclassification journal is booked, every time.

Why does a prepayment go on the balance sheet instead of straight to expense?

Because paying is not consuming. The cash left in one month; the benefit arrives across the service months. The amount sits in prepaid expenses and other current assets, with any tail beyond one year or the operating cycle classified as non-current. Amortizing it as the service is delivered keeps each period's expense matched to what that period used.

What does an auditor need to rely on a prepaid schedule run from the ERP?

Evidence that the extract is accurate and complete, held in the workpaper: the report or search identifier, its parameters, the run time, the subsidiary context, and the completeness and population checks. Where system controls cannot be relied on, that evidence is what gets tested.

Can the prepaid reconciliation be automated?

The preparation can be, including the schedule extract, the three proofs, the line scan, the exception aging, the evidence capture, and the routing for review. The decisions cannot: policy, thresholds, the treatment of judgment items, and sign-off remain with the accountant.