Skip to main content
← All posts

Paid a Year Upfront? Put the Service Period on the Slack Request

October 7, 2026 · BuyFlow Team

Someone in Slack asks to renew the team's design software for another year. It's $9,600, paid upfront, and it's approved in two minutes. A few weeks later the bill gets coded the way most software bills get coded: straight to the software expense line. That month's P&L takes the whole $9,600. The next eleven months show the tool as free.

Nothing was wrong with the approval. The problem is that the request said what was being bought and how much it cost, but not when the business gets the benefit. For anything paid ahead of time, that one missing field is the difference between a clean month-end and a reclass someone has to remember to do.

This post covers what a prepaid expense is in practical terms, which Slack requests should be flagged as one, what to capture on the request, and how QuickBooks Online and Xero will expect finance to book it.

Why "paid now, used later" needs its own treatment

A prepaid expense is a payment for something you'll receive over future periods: an annual insurance policy, rent paid in advance, a yearly software subscription. Intuit describes prepaid expenses as assets that sit on the balance sheet and are then expensed over time as the benefit is consumed, so the cost lands in the same periods as the benefit. That's the matching principle under US GAAP (QuickBooks help: prepaid expenses and amortization).

Xero's guide uses the same example most finance teams know by heart: pay a $12,000 annual insurance premium in January and expense it that month, and January's profit looks artificially low while the following eleven months look inflated because no insurance expense shows up (Xero US: Prepaid expenses).

For a growing company, that distortion shows up exactly where people are looking: department budget-vs-actuals, monthly burn, and any month-over-month comparison a founder or investor reads. One annual renewal can make a team look massively over budget in one month and under budget for the rest of the year.

Intuit names the two common mistakes directly: expensing all prepaid payments immediately, and forgetting to amortize, which leaves the prepaid amount sitting on the balance sheet forever (QuickBooks help). Both start upstream of the books, at the moment someone approved a purchase without saying it covers a period.

Which requests to flag

Not every upfront payment deserves a schedule. ExpenseFlow's Xero guide puts it plainly: materiality sets the threshold, and spreading a small subscription can be more effort than it's worth (ExpenseFlow). Pick a dollar line in your spend policy, and below it, expense as paid.

Above that line, the requests that usually qualify:

  • Annual or multi-year software and SaaS contracts paid upfront.
  • Insurance policies (general liability, D&O, cyber).
  • Rent, coworking memberships, or storage paid more than a month ahead.
  • Retainers and support contracts that cover a defined service window.
  • Event sponsorships or conference booths paid months before the event happens.

The common thread is a clear service period that starts and ends on known dates. If the requester can't say when the benefit starts and stops, that's a useful question to ask before approving anyway.

What to capture on the Slack request

The approver doesn't need to know anything about amortization. The request just needs to carry what finance will need when the bill arrives.

1. Service start and end date. Not the invoice date or payment date: the dates the coverage, license, or service actually runs. A subscription paid on March 20 that starts April 1 has a different schedule than one that started March 1.

2. Billing structure. Paid upfront in full, paid in installments, or billed monthly. Only the upfront portion that covers future periods is a prepaid. A monthly-billed contract is just a recurring expense.

3. The expense account it will eventually land in. Software, insurance, rent. The prepaid sits in an asset account first, but the monthly release still needs to hit the right expense line and department, class, or tracking category. If your team already codes the request in Slack, this is the same field.

4. Tax on the invoice, separated. In GST/VAT countries, the tax on an upfront payment can usually be claimed when the bill is recorded, not spread with the expense. Fuel Accountants' Xero walkthrough calls this out: code the sales tax correctly on the annual payment because you can claim it all back now, and keep tax out of the monthly release entries (Fuel Accountants). The request should store the net amount and tax separately when the quote shows them.

5. A "prepaid" flag. One yes/no field above your threshold. It's what lets finance filter open approvals at month-end and see which incoming bills shouldn't go straight to expense.

How it gets booked in QuickBooks Online

A QuickBooks Community walkthrough lays out the standard setup: create an account with type Other Current Assets and detail type Prepaid Expenses, record the payment to that account, then post a monthly journal entry that debits the real expense account and credits the prepaid account for one period's share (QuickBooks Community). Intuit's worked example is a $12,000 policy released at $1,000 per month for twelve months (QuickBooks help).

To avoid keying that entry twelve times, QuickBooks lets you click Make recurring on a journal entry before saving it and schedule it monthly. A QuickBooks team member notes one catch: recurring journal entries copy the same amounts on schedule and won't adjust themselves if the amortization amount changes, so you'd update those by hand, or use the Reminder type to get prompted before each one posts (QuickBooks Community). FinOptimal also suggests separate prepaid accounts for different types (insurance, software) so the balance is easier to track (FinOptimal).

This is where the service dates from the Slack request pay off. The recurring entry's start date, frequency, and number of occurrences come straight from them.

How it gets booked in Xero

Xero has a naming trap worth knowing. ExpenseFlow points out that two different things get called a "prepayment": money paid before any document exists (a deposit), which uses Xero's prepayment transaction type from bank reconciliation and is allocated when the bill arrives; and a prepaid expense, an annual cost consumed monthly, which is handled by coding the bill to a prepayments asset account and releasing it with a repeating manual journal (ExpenseFlow). Xero's prepayment transaction type does not spread costs over time (same source).

For the prepaid-expense case, the steps are: code the bill line to the prepayments current-asset account instead of the expense account, set up a repeating journal dated the last day of each month that debits expense and credits prepayments for one month's share, and give it an end date at the final month so it stops on its own (ExpenseFlow; Xero US).

Some accountants prefer a repeating bill instead of a manual journal: a two-line bill with a positive line to expense and a negative line to prepayments that nets to zero payable. Zenflow's argument is that manual journals aren't tied to a contact, which makes per-supplier prepayment schedules harder to report on (Zenflow). Fuel Accountants describes the same pattern and adds a practical tip: if the annual amount doesn't divide evenly, adjust the first month so the twelve releases add up to the exact total (Fuel Accountants).

Whichever method you use, the month-end check is the same: reconcile the prepayments account balance against a simple schedule of what remains unreleased per contract (ExpenseFlow). If every prepaid purchase was flagged at approval, that schedule is just a filtered list of approved requests with their service dates.

Books and taxes can treat it differently

The monthly schedule is about accurate management reporting. Tax can work differently. Xero's guide notes that the IRS generally allows prepaid expenses to be deducted in the year paid if the 12-month rule applies (Xero US). The underlying regulation says a taxpayer isn't required to capitalize amounts paid for a right or benefit that doesn't extend beyond the earlier of 12 months after the benefit starts or the end of the tax year following the year of payment (26 CFR § 1.263(a)-4(f)).

That's a conversation for your accountant, not your approvers. But it's one more reason to capture real service dates on the request: both the book schedule and the tax question depend on when the benefit starts and ends, not on when the invoice was dated.

A short checklist

For any Slack purchase request above your prepaid threshold:

  • Service start and end dates, not just the invoice date.
  • Billing structure: upfront, installments, or monthly.
  • The expense account and department, class, or tracking category for the monthly release.
  • Net amount and tax shown separately when the quote includes tax.
  • A yes/no prepaid flag so finance can filter at month-end.

With those on the request, the bill gets coded to prepaid the first time, the recurring release is set up from dates someone already confirmed, and nobody's budget line takes a twelve-month hit in a single month.

Sources