Agreement billing migration: 5 settings to check first

• Cutover date: choose one date for the whole batch against the billing calendar.
• Next billing date: carry it over from the old system and check it against a sample.
• Start date: match it to the original agreement, with renewal dates labeled separately.
• First charge: confirm elapsed time calculations by hand and explain charges to customers in advance.
• Prepaid balances: reconcile them before and after the move with your accountant's guidance.

Each agreement has a start date, a next billing date, and a record of what the customer has already paid. If any of those values arrives in the new system wrong, the customer sees the error on an invoice, and someone on your team spends time tracing it back to the source. This post covers five settings to check before you switch billing over. Work through them in order, because the cutover date shapes the rest.

The post is written for owners and office managers who run maintenance agreements themselves, whether those agreements are for equipment, software support, or building service. You do not need to be a billing specialist to use it. You do need access to the old records, a copy of the signed agreements, and a person who can make decisions about exceptions. If you are missing any of those three, sort them out before you pick a cutover date.

These checks are general. Where a point is general practice, treat it as a starting place and test it against your own agreements and your own contracts. Nothing here replaces advice from your accountant or your attorney.

The first setting to check is the cutover date, the day the new system takes over billing for the agreements you are moving. Pick it deliberately, and use the same date for every agreement in a batch so that the records you carry over all describe the same moment.

Stripe's guide on backdating subscriptions uses a single migration day in its example. The example opens with the sentence "For example, you're migrating on October 15." ( Stripe, "Backdate subscriptions" ) The date in that example is only an illustration.

Before you choose a date, look at your billing calendar. Which agreements renew in the weeks around the cutover? Which invoices have been sent but not yet paid? Which customers have asked for a change that is still pending? Write the answers down. A cutover that falls in the middle of a billing cycle may leave more agreements partway through a period than a cutover at a cycle boundary would, so the calendar is worth checking before you commit to a day. Use the maintenance billing calendar guide to organize that review.

Freeze changes to agreements for a short window around the cutover, if you can. If a customer upgrades, cancels, or changes billing frequency during the export, the snapshot you move may no longer match the agreement the customer actually holds. A short freeze, announced to your team in advance, keeps the export and the live records aligned. Decide who is allowed to make changes during the window and who approves exceptions, so that nobody has to guess.

Choose the time of day for the cutover as well as the date. Write down the time zone your team uses, and make sure the export is taken at a moment everyone agrees on. An export taken at the wrong hour can include a change that the customer has not yet seen, or leave out one that has already been made. Store the export file somewhere your team can find it, with a clear name that shows the date and time it was taken.

Keep each agreement's next billing date from the old system instead of resetting it to the migration day. Stripe's guide says that when you migrate subscriptions to Stripe, you can "carry over their next billing dates from your previous system while charging customers for elapsed time." ( Stripe, "Backdate subscriptions" )

The guide's example shows what that looks like: "A subscription started on September 1, and its next billing date is November 1." Use the same structure for your own check. For each agreement, you should be able to name a start date and a next billing date, and confirm that both match what your old system recorded. If the new system shows a different next billing date, stop and find out why before the first invoice runs.

Sampling helps here. Pull a small set of agreements from each billing frequency you use, such as monthly and annual, and check them by hand against the source records. A mistake in how one pattern is set up can repeat across every agreement that uses that pattern, so a close look at one example of each pattern can catch a problem that a quick scan of a long export would miss.

If an agreement has a next billing date that falls before the cutover, decide with your team how that case will be handled. Write the rule down so that the same choice is made for every agreement in the same situation. A written rule also protects your staff. When two people handle similar cases in different ways, the difference is hard to explain later, and a customer who compares notes with a colleague will notice it.

Check the status of each agreement at the moment you export it as well. An agreement that is paused, in dispute, or waiting on a signature needs a different entry from one that is simply active. Mark those agreements on the list before the migration starts, so they are not moved by default along with the rest.

Set each agreement's start date to the date the agreement began, not the day you move it. Stripe's migration example also sets the new subscription's start_date to the original start date. ( Stripe, "Backdate subscriptions" )

The start date is the anchor for the calculations that follow it. A wrong start date can flow into the next billing date and into any charge for elapsed time, so it is worth checking before anything else in the record moves.

Pay attention to agreements that changed hands. If a customer or a service contract was transferred from another owner or another entity, the start date may refer to the earlier relationship, the new one, or both. Find the document that shows the transfer, and decide which start date your business is entitled to use. That decision belongs with whoever signs for the business, not with the person doing the data entry.

For each agreement you move, compare the start date in the new system with the signed order form, the original contract, or the first invoice in the old system. Use whichever document your business treats as the record of the start. If those sources disagree with each other, resolve the disagreement before the migration, not after. This is a reconciliation task, and it is much easier to do with the paper trail open on your desk.

Watch for agreements that were renewed, extended, or re-signed. A renewal may carry a new term start date while the original relationship with the customer began earlier. Decide which date your business uses for each purpose, and label the two clearly in the record so that later staff can tell them apart. An unlabeled pair of dates is easy to misread when someone opens the agreement months later and sees only one of them.

Decide how the new system will charge for the time between an agreement's original start and the migration, and confirm the amount before any invoice is issued.

Stripe's guide also describes what happens at the moment of migration in its example: "This immediately issues an invoice for the prorated amount covering the time between September 1 and November 1." ( Stripe, "Backdate subscriptions" ) Plan for that. Know which customers will receive an invoice on cutover day, how large each invoice should be, and what each invoice should explain to the customer.

Tell customers before the change happens. A short, plain note that explains a first invoice may cover time that has already passed can reduce questions when the invoice arrives. Keep the note factual. Say what the invoice covers, when the next regular invoice will come, and who to contact with a question. Do not promise a result you have not checked.

Also check the figures by hand for a few agreements. Compare the proration you expect, based on your contract terms, with the amount the new system shows. If the two differ, find out whether the difference comes from the calculation method, the dates used, or rounding before going live. For that comparison, use the maintenance agreement proration guide .

Decide what happens to an agreement that is already in credit when the migration takes place. You may carry the credit into the new system, apply it to the first invoice, or handle it outside the system altogether. Each choice has different consequences for the customer's statement and for your records, so write the decision down and tell the customer what to expect. Ask your accountant or attorney before you settle on an approach, since the right answer depends on your contracts and your local requirements.

Also plan for a customer who disputes the first invoice. Keep the source dates and the calculation for each affected agreement in one place, so that the person answering the dispute can show exactly how the amount was reached. A dispute that can be answered from one page is easier to close than one that requires digging through two systems.

Check how prepaid agreements are recorded so that their balances move into the new system without changing what your books show. OpenStax's chapter on identifying and describing current liabilities works through an example with the assumption that "the customer prepaid the service on October 15, 2019." ( OpenStax, "12.1 Identify and Describe Current Liabilities" ) The same section shows journal entries for the prepayment of future services and for the revenue earned in 2019. ( OpenStax, "12.1 Identify and Describe Current Liabilities" )

Ask your accountant which entries apply to your prepaid agreements and how the opening balances should be recorded in the new system.

When you ask, bring a sample of two or three real prepaid agreements, with the payment date, the service period, and the amount still unused on the migration date. Concrete examples make the conversation faster and reduce the chance that a general answer gets applied to a specific case it does not fit.

Export prepaid balances as a separate list, then total them before and after the migration. If the totals differ, do not move on until you know why. A reconciliation like this is simple to set up at the start and far harder to rebuild after the old system has been switched off. Keep a copy of the list with the migration records. Store the export in the same place as the agreement records, so that anyone reviewing the balances later can trace each total back to its source.

If your old system can export prepaid balances with the payment date and the service period on each line, use that export rather than retyping the figures. Hand-typed totals are a place where small errors can enter, and a direct export keeps the link to the original record. Check the export's total against the old system's own report before you rely on it.

Pay particular attention to prepaid agreements that span the cutover date. The part of the prepayment that has not yet been used at the time of migration may need its own treatment, and it is easy to miss if the list only shows the total amount paid. Mark those agreements on the list so they get a second look.

Illustrative example of a prepaid balance check

An illustrative agreement has a $55 prepayment, with $5 already used at cutover. If it shows $55, investigate before billing: the amount paid and the amount still unused are different figures.

Run all five checks on a sample of agreements before you move the full set. If your new system offers a test environment, use it, so that a wrong date or a wrong balance can be found and fixed quietly. If it does not, work from a copy of the export and compare each result against the source records by hand.

Write down what you checked, who checked it, and what you decided for each exception. This record matters when a customer asks later why an invoice looks the way it does, and it matters to whoever inherits the system after the people who ran the migration have moved on. A short document is enough. It should list the five settings, the sample you used, the results, and the rules you wrote down for the edge cases.

After the cutover, watch the first billing run closely. Compare the invoices against your sample, and make sure someone on the team who knows the agreements is available to answer questions that day. Keep the old system readable for a while so you can look up an original record if a question comes up after the switch. Do not delete source records until the reconciliation is finished and signed off.

Assign one person to own each setting. That person does not have to do all the checking, but they should be the one who signs off that the setting matches the source records. Give the list to the owner of the business as well, so that the person who is accountable for the agreements can see the status of each check without asking for it.

Finally, schedule a review according to the agreements' actual billing dates and frequencies. Any pattern that shows up in that review belongs on the list for the next batch, and the next migration will be easier for it.

Today, choose a sample agreement and compare its dates and unused prepaid balance with the original records.

Related guides: Field service settings to verify: 8 job checks .

Should the migration day become the next billing date?

Keep the next billing date from the old system rather than resetting it to the migration day.

What should you do when prepaid totals differ?

Find the reason for the difference before continuing the migration.

When should you review the first invoices?

Review invoices when the migrated agreements reach their actual billing dates.