MCA Remittance Changes: A Controlled Workflow for Funders
By Johnny Accardo · Founder & CEO, Big Tuna Solutions
A practical MCA remittance-change workflow for reviewing requests, versioning approved terms, coordinating updates, and reconciling the first changed payment.
Open a request without changing the live schedule
Create a request record when the merchant, account owner, servicing team, or another permitted source asks for a change. Capture the deal identifier, current remittance details, requested change, stated reason, request date, source, supporting material, and person responsible for the next review. Keep the request in a pending state while the existing schedule remains the operational baseline. Recording a request is not the same as approving it, and the live payment record should not be edited simply because a conversation has started.
Build the review from current account facts
Give the reviewer the current agreement version, payment history, remaining balance used by the organization, open servicing exceptions, prior remittance changes, recent merchant communications, and any documents required by the team's process. Note the source and as-of time for balances and payment activity so a reviewer can tell whether the file changed during review. This is an operations packet, not an automated decision: the authorized person should be able to see the relevant facts without reconstructing the account from several systems.
Separate the decision from the requested terms
Record the decision, decision date, authorized reviewer, source evidence, and any conditions separately from what the merchant originally requested. If the approved amount, frequency, start date, or duration differs from the request, preserve both versions. Use the outcome labels the organization has established, such as approved, declined, more information needed, or withdrawn. The workflow should document and route the decision; it should not infer contractual rights, eligibility, or legal obligations.
Create an effective version of the remittance schedule
For an approved change, create a new schedule version that shows the applicable amount or percentage, frequency, first effective date, expected duration or review point, approval reference, and any related instructions. Keep the previous schedule available with its own effective period instead of overwriting it. Check the proposed effective date against payments already submitted or pending so the team does not create two competing expectations for the same period. A versioned record makes it clear which schedule governed each payment.
Coordinate every downstream update from one checklist
List each operational destination affected by the approved change, such as the servicing record, payment processor instructions, merchant communication, account-owner tasks, participation records, and internal reporting. Assign an owner and completion evidence to every applicable item. Marking the request approved should not imply that each downstream update happened. A shared checklist exposes partial handoffs, including a merchant notice sent before payment instructions were updated or a processor change made without the current approval reference.
Reconcile the first payment under the changed schedule
After the effective date, compare the expected payment with the actual transaction using the team's source records. Match the deal, schedule version, amount, date, status, and transaction reference. Route missing, duplicated, partial, returned, or old-schedule payments into an owned exception rather than silently adjusting the request record. If the first changed payment does not post as expected, the team needs to know whether the problem is timing, instructions, processing, account data, or another issue before it treats the new schedule as operational.
Close the change only when the handoff is complete
Close the workflow when the decision is documented, the effective schedule is recorded, required communications and operational updates have evidence, and the first applicable payment has been reconciled or moved into a separate exception process. Retain the request, review packet, decision, version history, checklist, and transaction evidence together. Review queues for pending requests without owners, approvals without effective versions, effective dates that have passed without confirmation, incomplete downstream updates, and changed schedules whose first payment remains unmatched.