Prepaid Expenses: Building the Amortization Schedule From the Invoice Service Period
An annual insurance premium or software renewal lands in one month and covers twelve. Book it straight to expense and that month looks like a loss while the next eleven look better than they are. Prepaid schedules fix the timing, but only if every qualifying invoice gets onto one, with the right dates. This post covers how a bookkeeping firm builds those schedules from the invoice itself and ties them out for every client at month end.
In brief
- A prepaid expense is a payment for a service period that has not happened yet; it sits on the balance sheet and moves to expense month by month as the period runs.
- The invoice states the service period, so the schedule should be built from the invoice dates, not from the payment date or a guess at the term.
- Each month the prepaid account in the general ledger should equal the sum of the unamortized balances on the schedule; a gap means an invoice was missed, expensed in full or amortized over the wrong period.
- Extracting the service start and end dates from every invoice above the firm's threshold lets a bookkeeping firm build and tie prepaid schedules for every client without reading each invoice by hand.
What makes an expense prepaid
A prepaid expense is a payment made now for a service the client will receive later. The payment is not yet an expense, because nothing has been consumed; it is an asset on the balance sheet. As each month of the service period passes, the share that has been used moves from the prepaid account to the expense account it belongs to. When the period ends, the prepaid balance for that invoice is zero and the full amount has been expensed, spread evenly across the months that benefited.
The usual suspects are insurance premiums, annual software subscriptions and licences, maintenance and support contracts, rent paid in advance, trade memberships and annual service agreements. What they share is a service period printed on the invoice or the policy: a start date and an end date. That period, not the invoice date and not the date the money left the bank, is what the schedule follows.
Prepaids are the mirror of accruals. An accrual books an expense before the invoice arrives; a prepaid holds back an expense after the invoice is paid. The post on received-not-invoiced accruals covers the other side. Both exist so that each month carries the cost of what it actually used.
2
dates on the invoice that drive the schedule: service start and service end
1,000
monthly amortization on the example premium: 12,000 over 12 months
3
checks in the example tie-out below
How the schedule runs
Take a hypothetical client that pays an annual general liability premium of 12,000 in September for a policy running from October 1 to September 30. On payment, the full 12,000 goes to prepaid insurance. At the end of October, 1,000 moves to insurance expense, leaving 11,000. By the end of March the balance is 6,000, and on September 30 it reaches zero, exactly as the policy expires.
When the service period starts on the first of a month, a straight monthly split is clean. When it starts mid-month, as most software subscriptions do, a daily rate is more accurate: divide the amount by the days in the period and multiply by the days that fall in each month. The schedule then ends at exactly zero on the service end date, with no rounding left behind in the account. Whichever method a firm picks, it should pick one and apply it to every client, so that a reviewer can recompute any line.
Most firms also set a materiality threshold: invoices below it are expensed as paid even when they cover a future period, because the distortion is too small to justify a schedule line. The threshold is a policy choice agreed with the client, and tax treatment can differ from book treatment, so the client's tax preparer should know what it is.
Where prepaid accounts stop tying out
Across a portfolio of small-business clients, the prepaid account drifts for a handful of recurring reasons, and almost all of them start with an invoice that was categorized without anyone reading its dates.
The annual invoice expensed in full
The most common break. A bank rule or a quick categorization sends the renewal to software or insurance expense, the prepaid account never sees it, and the client's month looks far worse than it was. The following months look better, and the year total is right, which is why this one survives until someone reads the monthly reports closely.
Wrong start date, wrong term
Starting amortization on the invoice or payment date instead of the service start shifts expense into the wrong months, and a renewal paid weeks early can put two policies on the schedule at once. A multi-year contract booked as twelve months, or a quarterly invoice booked as annual, leaves a balance that either runs out early or never clears.
Changes during the term
A cancelled policy with a pro-rata refund, an insurer audit that adds premium, or seats removed from a subscription with a credit note: each changes the remaining balance, and each arrives as a separate document the schedule has to absorb.
Annual invoice expensed in full
Started at payment, not service date
Renewal overlapped old schedule
Cancellation or refund not reversed
Wrong term or end date
Other
Building schedules from the invoice, step by step
For one client with three prepaids, a spreadsheet does the job. For a firm with a hundred clients, each paying a dozen annual invoices from different vendors at different times of year, the work is finding the invoices that qualify and reading their dates. That is a reading problem, and it scales the same way as receipt-to-bank matching and loan statement reconciliation: turn every document into the same fields, then let rules compare.
1. Extract the service period from every invoice
For each invoice above the threshold, capture the vendor, invoice number and date, the amount, the service period start and end, and the line description. Typing the dates as ISO dates and the amount as a number, as the post on extraction schema design describes, means the schedule can be computed without anyone retyping a field. Insurance documents often arrive with the declarations page, endorsements and the invoice in one PDF; split them first, as covered in splitting and classifying mixed PDF batches.
2. Generate the schedule line
From the two dates and the amount, compute the days in the period, the daily or monthly rate, the amortization for each month and the unamortized balance at each month end. An invoice with no service period, or one shorter than a month, is not a prepaid and goes to expense as normal.
3. Tie the schedule to the ledger
At month end, the sum of unamortized balances on the schedule should equal the prepaid account in the general ledger, and the amortization posted should equal the schedule's total for the month. Every invoice on the schedule should also tie to a payment in the bank or a bill in payables, so nothing is on the schedule that the client never actually paid.
{ "client_id": "client-0342", "period": "2026-09", "invoice": { "vendor": "example-software-vendor", "invoice_number": "INV-20931", "invoice_date": "2026-09-10", "amount": 4380.00, "service_period_start": "2026-09-15", "service_period_end": "2027-09-14", "description": "Annual subscription, 25 seats" }, "schedule": { "days_in_period": 365, "daily_rate": 12.00, "amortization_this_period": 192.00, "days_this_period": 16, "unamortized_at_period_end": 4188.00 }, "ledger": { "prepaid_account_balance": 0.00, "software_expense_posted": 4380.00 }, "checks": [ { "check": "invoice_on_schedule", "status": "break", "hint": "Service period runs 12 months; invoice posted in full to software expense" }, { "check": "prepaid_balance_vs_schedule", "schedule": 4188.00, "ledger": 0.00, "difference": -4188.00, "status": "break" }, { "check": "invoice_vs_payment", "invoice": 4380.00, "bank_debit": 4380.00, "status": "ties" } ], "proposed_entry": { "debit": { "account": "Prepaid expenses", "amount": 4188.00 }, "credit": { "account": "Software subscriptions", "amount": 4188.00 }, "requires_review": true }}In this example, a 4,380.00 annual subscription covers September 15 to September 14 of the next year, 365 days at 12.00 a day. Sixteen of those days fall in September, so 192.00 belongs to the month and 4,188.00 should still sit in prepaid. The ledger posted the whole invoice to software expense. The payment ties to the bank, so the fix is one reclassification of 4,188.00 into prepaid, reviewed before it posts, after which the schedule takes 372.00 in October and continues from there.
The service period is on the invoice
Keep the numbers honest
Treat extracted dates as a draft until they pass simple checks: the end date falls after the start, the period length is a plausible term (a month, a quarter, a year, a multi-year contract), and the amount matches the payment. A one-year policy that extracts as running for one day is a misread, not a short policy. Keep a labelled set of invoices from the vendors that appear most across clients and score the date fields when a vendor changes its layout; the post on building a field-level eval set explains how. And route every reclassification through a reviewer rather than posting it automatically.
Monthly prepaid reconciliation: a checklist
- Agree a materiality threshold with each client and write it down.
- Flag every invoice above the threshold that covers a period longer than one month.
- Extract vendor, invoice number, amount and the service period start and end dates into one schema.
- Compute each schedule line from the service period, using one method across all clients.
- Tie the sum of unamortized balances to the prepaid account and the month's amortization to the expense posted.
- Match every schedule invoice to a payment or a payable, and absorb refunds, audits and credit notes as they arrive.
- Post each correcting or reclassification entry only after review.
Where extraction fits
The accounting for a prepaid is simple; what slips across a portfolio is spotting which invoices qualify and reading their dates correctly, for every client, every month. Parser turns each invoice into structured JSON against an extraction template you define, including the service period fields, so prepaid schedules are built from data and the team's time goes to the breaks.