How to Plan Payment Milestones for Overseas Projects: Delivery, Invoicing, and Receipt

Overseas project payments can stall across three dates: delivery is complete, an invoice has been sent, but the client’s money has not reached your account. Put all three in one tracker, noting who confirms each step, what evidence triggers invoicing, and when to review again. The hypothetical USD project below is for process practice only; actual milestones depend on the parties’ documents and the client’s payment process.

How should each milestone be defined?

Describe each milestone so both sides know what “complete” means; avoid labels such as “Phase One complete.” Record the deliverable and scope, acceptance evidence, client contact, completion conditions, target date, invoice trigger, and amount. If progress depends on client materials, access, or decisions, note the owner and due date. This exposes delays without treating internal effort as client acceptance.

The example assumes a USD 12,000 project, same-day client acknowledgment of each invoice, and a contract requiring payment within 14 calendar days of receipt. Dates and percentages are illustrative only.

The amounts total USD 12,000 and the percentages total 100%. Keep one definition of “complete” in the tracker; list sub-items or split them into separately confirmable rows. Preserve baseline and latest update dates with a short note distinguishing the original plan, client changes, and internal tasks.

Use a deliverable with verifiable status—for example, three agreed pages in a test environment, an access link, and client confirmation in the feedback log. For consulting or research, specify retained outputs such as a summary, data inventory, or decision record rather than hours or meeting counts. Tie fee and trigger to the same row; split milestones when sub-items make payment status unclear.

Who confirms that delivery is complete?

Delivery and client acceptance are different statuses. The internal owner confirms delivery as agreed; the designated client contact confirms receipt, acceptance, or required revisions. Follow the agreed scope and process; internal testing is not client confirmation. Labels such as “submitted,” “awaiting client confirmation,” “revision needed,” and “confirmed” are team tracker statuses, not statements of legal effect.

If a prototype was sent but the client has not replied, log the send time, version link, recipient, expected reply date, and next contact. Keep the status at “awaiting client confirmation”; do not mark it accepted or invoice when acceptance is the trigger. If the client requests two changes, list each item, owner, and target date, then send the updated version and retain the history. Save the confirmation required by the parties’ documents; if the method is unclear, align in writing before invoicing.

Keep links, versions, send times, and replies in a shared location; state the outstanding response, owner, and next review date. At kickoff, agree who can confirm for the client, the acceptable format, and where to consolidate feedback. Name one reviewer to reconcile comments. For staged acceptance, retain each submission and confirmation. Before sending, check file access and attachments; these are delivery records, not proof of acceptance.

When should invoicing details be ready?

Prepare invoice details before the trigger, so finance is not chasing information after delivery. Track the legal billing name and address, contracting entity, required purchase order or project number, currency, amount, description, recipient, invoice format and delivery method, source of payment terms, and reviewers. Use signed documents and confirmed client instructions; do not copy old recipient details, since the billing entity may differ.

A draft record may be prepared early, but label it “trigger pending” to prevent early sending. Once acceptance or another agreed condition is met, verify currency, amount, and recipient. Record owners and materials for vendor onboarding, purchase orders, or portal submission, allowing time for processing. Cross-border invoicing, tax, and accounting treatment depend on the facts and applicable rules; this article sets no tax rate or filing deadline. Ask a qualified accounting or tax professional about a specific case.

For a milestone expected to be accepted on Nov 8, finance can check the billing name and purchase order fields on Nov 1, then send after the trigger is confirmed. Keep the sent version, time, and receipt confirmation. If the billing address is unknown, record who asked the client and when an answer is due; do not guess.

Use statuses such as “not collected,” “awaiting client confirmation,” “reviewed,” and “ready to invoice,” noting each field’s source. Before sending, have a second person compare entity and billing name, amount and milestone, currency and agreement, and recipient and current contact. If a purchase order amount differs, check for a split order or amended document; do not change the amount to force a match.

How should you estimate the expected receipt date?

An expected receipt date is a planning estimate, not a promise. Check the contract or confirmed payment document for the event that starts the payment period: invoice date, client receipt, acceptance, or another stated condition. Check for client payment runs, vendor reviews, and bank or external payment-service processing time. Track the reference due date and expected funds-received date separately, with their source and last confirmation date. If terms are unclear, seek confirmation instead of assuming customary days.

The example’s written terms require payment within 14 calendar days after invoice receipt. If the client acknowledges receipt on Nov 8, Nov 22 is the reference due date. Confirm the client’s payment run and transfer process before estimating arrival; mark it “awaiting client confirmation,” not guaranteed. If monthly batches apply but this invoice’s batch is unconfirmed, show this-batch and next-batch scenarios with each condition. Do not invent probabilities.

When the forecast changes, update the date and reason while retaining the prior version. Three useful cases are payment on the agreed date, deferral to the next client payment run, or a delay while receiving details are corrected. For each, record the assumption, forecast date, evidence, and update owner; mark it “scheduled” only after client confirmation or a payment notice. If exchange rates affect internal cash planning, record the planned rate source or date separately from the actual bank credit.

A payment platform may have a separate merchant-payout process. This tracker covers expected payment for a client project, not Stripe payout reconciliation.

Who should contact the client when payment is delayed?

Assign the payment contact before work starts so project, sales, and finance do not assume someone else will follow up. One account contact sends the invoice and confirms receipt and payment status; the project owner provides delivery context; finance checks bank activity. Record primary and alternate contacts, channel, last contact date, reply deadline, and next action. If receipt is unconfirmed, resend or verify details. Before the payment date, ask about the payment run at the agreed cadence. If it passes, record the reason and revised date, then escalate internally for contract-based handling if needed.

If funds were expected on Nov 22 but are not visible on Nov 23, check the currency, beneficiary details, invoice number, and bank posting time. Ask the client’s finance contact whether payment was arranged, for what date, and whether a transfer reference is available. If the reply is “next week,” request a trackable date. If the client reports a bank review or returned details, pause repeated reminders and identify the missing item and each side’s owner.

Refer to the same invoice number, milestone, and amount in every message. State the next action and reply time for anyone taking over. Log why each date changed, such as missing information, a moved payment run, or a transfer still processing; do not use one generic “late” label. Start with a low-friction request attaching the invoice and documented payment-date basis. If there is no reply, remind at the team’s chosen interval and log it. Give managers the documents, replies, and open decisions. Separate disputed items from amounts already confirmed. Set cadence by agreement and client relationship; these practices are not statutory collection deadlines.

How do you reconcile the amount received?

Reconcile each invoice with each client payment, not just the project total. Compare invoice number, payer, receiving account, currency, posting date, bank amount, transfer reference, and open balance. List partial or installment payments separately and link each to the invoice. If invoice and bank net credit differ, check bank notices, payment evidence, and the parties’ documents for fees, exchange-rate movement, deductions, partial payment, or a mismatch. Finance decides how to record or collect the difference; do not silently remove it.

For a USD 3,600 invoice with a USD 3,580 credit, record USD 3,600 invoiced, USD 3,580 received, an unresolved USD 20 difference, and the evidence source. Mark it “pending reconciliation” until explained; do not mark it fully settled. If the client pays through a platform, retain the client payment and platform batch payout records separately. The payout is downstream funds reconciliation and can be linked from its own record.

Record the reconciler, date, and close condition. Close only when the invoice matches the payment or the supported difference is documented. At month-end, filter for invoices sent but not received, past-due invoices not received, and receipts not matched; assign an owner and feed delay reasons into the next forecast.

To prevent duplicate allocation, record the bank reference or payment notice and the invoice assigned to each receipt. If one payment covers multiple invoices, preserve allocations and confirm they add up to the receipt. If the payer name differs, verify it against transfer details and with the client; do not auto-match on amount alone. Keep the original number, correction reason, and reviewer when records change, so the report remains traceable.

For background on Chan & Chung as a consultancy, visit the Chan & Chung English homepage.