Contractor Processor Switching Checklist: Job Records and Field Collection

Preserve job and invoice references for field collection

Before a contractor changes processors, map open jobs, deposits, staged invoices, approved changes and the job-software connection. Confirm which field devices and payment channels the proposed account supports. Keep the office’s authoritative job balance distinct from any collection app’s display.

Pilot a fictional staged payment, a scope change and an interrupted field result. Ask the technician to use normal permissions and the office to verify the invoice posting. Define how both teams discover a payment made through an older invoice link during the transition.

Keep old payment references available for refunds, disputes and final transfers. The cutover log should identify which provider owns each collection without requiring the customer to remember. Confirm migration and equipment obligations before removing accounts or access.

Write the reason for changing and the requirements to retain

Start with the problem the change must solve: an explainable cost issue, an unsupported workflow, difficult reconciliation or an agreed operational improvement. Record current software, devices, channels, locations and staff roles. A new processing relationship should be assessed against those requirements rather than treated as a reason to replace everything.

Identify the components the business intends to keep. Ask the responsible parties to confirm exact compatibility, provisioning and support in writing. Existing ownership or a familiar device model does not establish that the proposed account or application can use it. A supported manual handoff should be documented as a limitation, not described as an automatic integration.

Set acceptance criteria and a stop decision before planning a launch date. The business needs to know what must work, who verifies it and what would pause the rollout. Avoid making the old system unavailable simply because the new equipment has arrived or an application has been submitted.

Review agreements and the complete proposed cost

Collect the existing obligations and the actual proposed agreement set. Separate processing, software, equipment, apps and installation. Identify duration, notice, return and access questions for the appropriate provider or adviser. Do not infer that cancelling one service ends all related obligations.

Compare the new proposal using the same representative volume, transaction count, channels and operating period as the current arrangement. Include migration, training, paid apps and required equipment. Keep conditional incentives and temporary rates separate. A lower headline transaction price is not enough to establish a lower total cost.

Have qualified advisers review legal, tax or accounting questions when needed. This checklist organises an operational change; it does not determine cancellation rights or guarantee a provider’s approval. Resolve material unanswered questions before treating the switch as ready, and retain the agreed documents with the configuration record.

Inventory the records that must survive the change

List open orders or invoices, customer balances, deposits, refunds in progress, disputes, required financial history and operational data. Identify the authoritative owner, export format, destination and reconciliation owner for each. Moving a customer name list does not transfer its financial history or payment permissions.

Keep payment-credential migration with the responsible providers and their approved secure process. Do not export card details into an ordinary spreadsheet or email them to a new vendor. Ask whether the relevant credentials or tokens are supported for migration, what authorisation is required and how references will be mapped. A business-data export is not proof of token portability.

Use a controlled sample before a complete import. Check identifiers, amounts, dates and required attachments or history. Retain a recoverable source export under the approved retention and access policy. A successful import message should be followed by an operational and financial check, not treated as independent evidence that every record is usable.

Pilot the new workflow with approved test records

Stage the actual sequence from business event through payment, receipt, correction and closeout. Use fictional records or the provider’s supported test facilities. Have ordinary staff roles complete the task, including a supervisor exception. An administrator’s demonstration may conceal permissions or configuration missing from the proposed daily setup.

Include an interrupted result and confirm how staff establish whether collection occurred before trying again. Test the links between systems as well as each individual device. A payment approval that never reaches the order, invoice or account can leave staff collecting twice or posting manual adjustments later.

Record observed results, dependencies, manual steps and unresolved issues. Obtain the responsible owner’s approval before broad deployment. Keep a supported fallback and decide how manually handled work will be reconciled if the launch pauses. A rollback plan needs access, references and named owners, not merely a promise to reconnect the old device.

Control the cutover and overlapping financial activity

Choose an agreed cutover point and communicate it to staff and relevant providers. Record the final operating activity on the old setup and the first activity on the new one. Keep provider, channel and business-day references distinct so the bookkeeper can explain which account owns each collection.

Confirm how later refunds and disputes on older payments will be handled. Do not assume the new terminal can adjust every old transaction. Preserve required access or an agreed support route for historical activity. A business can be operational on the new setup while financial exceptions remain with the prior provider.

Track final and initial transfers independently. Ask each provider about the applicable account-specific conditions instead of promising uninterrupted next-day funding. Keep outstanding fees, equipment actions and unresolved records on the migration log until verified. Avoid closing old access solely because the first new payment succeeded.

Complete the handover and verify the first operating period

Give staff an updated support sheet, task procedures and role permissions. Remove access through the approved process when it is no longer needed, including temporary migration or remote-support access. Retain records necessary for reconciliation and future enquiries in the business’s authorised location.

Review the first close and the first relevant settlement cycle with the financial owner. Check exceptions, charges, receipt details, staff attribution and operational outputs. Confirm that the quoted apps and services are the ones actually configured. Investigate deviations before replicating the setup at another position or location.

Keep a final checklist of accepted limitations and unfinished obligations. Record who owns each remaining item and its next check. The switch is complete when the team can operate, correct and reconcile the supported workflow and the remaining contractual or historical tasks are controlled, not merely when old hardware is unplugged.

Reconcile a sample migration before accepting the full import

Prepare a small fictional source set with three open business records: one unpaid amount, one partly paid amount and one credit or approved adjustment. Give each a unique reference and a clear expected remaining balance. Keep the example in approved test facilities or a planning worksheet so it does not create live receivables or customer demands.

Compare source and destination counts as well as totals. A matching total can conceal one duplicate and one omitted record. Check each identifier, status, amount, relevant date and the location of any required supporting history. Where a manual opening entry is authorised, retain the source reference and the owner’s approval rather than presenting the entry as a newly collected payment.

Add a late-arriving event to the exercise: a payment completes through an old link or an adjustment arrives after the initial export. The cutover owner should identify which system owns the event, how the destination is updated and how duplicate collection is prevented. A single import snapshot does not by itself explain activity occurring during the overlap.

Have a backup employee follow the references after the test. They should locate the current balance and the historical payment provider without using a migration consultant’s private notes. Record any missing information or unsupported field as a requirement to resolve before the full import, and agree what remains available in the old system under the applicable access arrangements.

Make the go-live and pause decisions explicit

List the conditions for proceeding: the supported collection route, correct business-record handoff, staff permissions, required receipts or operational outputs, accepted opening balances and a verified support owner. Identify the evidence and approver for each condition. An account application or shipped device is not a substitute for these operating checks.

Define the cases that would pause expansion or trigger the approved fallback. Examples may include an unexplained balance, an uncertain collection result or a critical output failing its acceptance test. The exact threshold belongs to the business and responsible providers. Keep the fallback’s financial boundary clear so work is not collected twice.

After the controlled launch, compare the observed close and transfer records with the accepted plan. Resolve any material deviation before copying the configuration to another device or location. Preserve unfinished historical, access and equipment obligations on the handover register even when routine new sales are working.

Maintain one cutover register for all owners

Create a row for each required component or record set. State the current owner, proposed destination, dependency, test evidence, cutover action and verification owner. Include software, devices, access, paid apps, open balances and financial references. Mark a critical requirement as unresolved until its actual supported result is demonstrated or an authorised limitation is accepted.

Separate operational go-live from final financial completion. A new register may be ready while the old provider still owns a refund, dispute or final transfer. Keep those historical cases on the register with access arrangements and next actions. Do not obscure them under a general completed-migration label.

Define who can stop the rollout and how staff are told. A fallback must identify the supported configuration and how any overlap is reconciled. Avoid having two systems collect the same order because each appears available. Use references and a clear operating boundary rather than relying on staff to remember which screen they used.

Check the handover with someone who did not configure it

Give a trained backup employee a fictional normal case, a correction and an unresolved-result case. Ask them to locate the business record, verify payment status, use the correct support route and produce the closing evidence. Observe which steps depend on undocumented knowledge or elevated access.

Have the financial owner inspect opening balances and the first old/new transfer comparison. Record any discrepancy and pause expansion if it affects a critical requirement. Keep the original exports and accepted configuration available under the approved retention policy so later questions can be answered without recreating the migration from memory.

Close each remaining action with evidence, not only a checkmark. A returned device needs the required acknowledgement; an exported balance needs reconciliation; removed access needs verification through the authorised process. Retain the final register as the starting point for the next location or future provider review.

What should the field employee receive at handover?

A supported device and account, authorised collection procedure, uncertainty stop rule and verified office or provider contact. Remove obsolete instructions and restrict settings to the appropriate role. A spare device or new shortcut is not ready until it has passed the actual job-to-payment acceptance check.

Prepare the review without exposing private records

Summarise the business, current software, payment channels, locations and the specific job invoice problem you want resolved. Include a non-sensitive example and the outcome you expected. That gives a review more direction than a general request for better rates or a new device. List existing components you want to retain so proposals account for them.

Process Rite helps organise the payment requirements, provider questions and written comparison. Availability, integration, account approval, implementation and service terms need confirmation in the applicable proposal and provider agreement. Hardware, software, applications and processing charges should remain identifiable. Request a custom proposal based on the configuration and channels your business actually needs.

Use the website enquiry for the summary, then arrange document sharing after contact. Do not submit payment credentials, bank logins, passwords or private customer records. Include your town and preferred callback time so the conversation starts with the right context. Consultations and any site work are arranged directly. Confirm the responsible support contact and available service hours in the proposal.

Sources and review scope

Documentation reviewed October 17, 2026. Provider documentation supports product-specific facts; it does not confirm another provider’s terms or the suitability of an individual configuration. These operating examples are proposed checks, not reports of hands-on product testing. Worked amounts and records are fictional.

Clover^®: contract and equipment questions

Stripe: provider-managed data migration overview

Related guides for your business

Contractor deposits and field payments

Contractor invoice links and online collections

Contractor job reconciliation

Contractor collection and office handoff

Contractor processing effective rate

Contractor declined card troubleshooting

Contractor deposit delay questions

Keep an acceptance checklist

• Required records and opening balances reconcile before cutover.
• The supported workflow passes normal, correction and interrupted-result checks.
• Old and new collections retain distinct provider and transfer references.
• Historical access, exit obligations and staff handover have assigned owners.

Discuss the configuration you actually need

Tell Process Rite your business type, town, current software and the specific question to review. Start with a non-sensitive summary and arrange document sharing after contact. Do not submit payment credentials, bank logins or private customer records.

Equipment, software, applications and implementation are separately quoted. Availability, integration, approval, pricing and service terms need confirmation in the applicable proposal and provider agreement. A review does not guarantee savings, approval, legal compliance or a dispute outcome.

Request a free payments review · Review the complete cost · Find the right support route