Migration & data
Migrating Plumbing Invoices: Do Not Guess the Paid Status
An imported invoice should be marked paid only when the source evidence supports that meaning. Preserve charges, balances, actual payments, and adjustments separately; a zero balance or a completed job is not enough to invent a payment transaction.
In this guide
Identify the source meaning of each field
Exports may include original total, balance due, amount paid, payment status, or another summary field. Read the definitions and inspect examples before deciding how those values map to the destination.
A field called “closed” could describe a workflow state rather than a verified customer payment. A completed job says something about work, not necessarily about billing or collection.
Have an accountant review financial classifications and reconciliation. This guide focuses on preserving evidence during migration.
Keep an invoice-and-payment map
Invoice migration review
Source invoice ID and number: [references]
Customer and job IDs: [references]
Original charge / applicable adjustments: [amounts]
Source remaining balance: [amount]
Actual payment references and allocations: [details]
Credit, refund, void or other resolution evidence: [details]
Source status definition: [documented meaning]
Destination status and reason: [mapping]
Unresolved financial question: [owner/action]
Do not manufacture missing payment dates or transaction IDs to satisfy required fields. Keep the record flagged for review or preserve it through the supported historical-data process.
Compare three fictional cases
| Source situation | What the migration must preserve |
|---|---|
| $500 charge, verified $500 payment | Charge and actual payment relationship |
| $500 charge, verified $200 payment | Charge, partial payment and $300 balance |
| $500 charge reduced by an approved $500 credit | Adjustment history, not an invented cash payment |
The examples ignore other complications solely to show the distinction. A zero remaining balance can have more than one explanation.
Similarly, a refund does not automatically mean the original payment never happened. Preserve the original transaction and the related reversal rather than deleting the history.
Reconcile totals with the same scope
Compare invoices and payments using the same customer set, date scope, currency, and status definitions. Do not compare all historical payments with only currently open invoices and expect equal totals.
Record export filters and cutoffs. Work entered after an export may explain a difference without indicating data loss. Conversely, an unexplained difference should remain visible until reviewed.
Test the destination's behavior
Some import paths may accept invoice history without native payment transactions; others may support both. Verify the actual current capability and its limitations before describing the result as a complete migration.
Check whether repeated imports create duplicates or update existing IDs. A retry must not create a second payment for the same source transaction.
Inspect the customer-facing invoice and any accounting integration after the test. A correct internal table is not enough if the displayed balance is wrong.
Keep exceptions out of normal collection workflows
An invoice with uncertain migrated payment status should not trigger an automatic customer reminder as though nonpayment were verified. Assign a review owner and resolve the evidence first.
Likewise, do not hide all uncertain records by marking them paid. That can conceal genuine outstanding balances.
The right outcome is an explainable status backed by source records. When evidence is incomplete, the migration should say so instead of creating a convenient but false financial history.
Sources and editorial notes
Product and documentation references checked September 29, 2026. GoPlumber publishes this guide about its own product category. Examples and templates are original illustrative material, not customer case studies or market benchmarks. Confirm current vendor terms before acting.