Prepare a clear EDF invoice schedule for multiple clients

Build a readable monthly schedule with customer-level invoice rows, currency totals and receipt references.

A monthly schedule is helpful only when individual invoices remain traceable. Combining several clients into one unexplained amount makes it difficult to answer later questions about partial payments, deductions or corrections. Treat the schedule as an index to the underlying evidence rather than a replacement for it.

Keep one identifiable row per invoice

Give every row an invoice number, date, customer, country, service description, currency and gross amount. Add receipt references or pending status without erasing the invoiced value. If one invoice has several receipts, use a linked receipt list rather than duplicating the full invoice amount on every payment row. Check that repeated customer names do not hide different legal entities.

Group carefully and keep exceptions visible

Confirm the authority’s accepted schedule structure. Separate currencies and invoice periods in the working view. Flag credit notes, disputed amounts and incomplete customer information so the reviewer knows what needs attention. Keep an invoice count and an attachment index. These small controls make it easier to detect an accidental omission than a large total on its own.

Design columns around traceability

Start the schedule with identifiers rather than a grand total. Useful working columns include invoice reference, issue date, customer legal name, country, service description, currency and gross value. Add receipt status and linked evidence separately. If two customers use similar trading names, retain enough detail to distinguish the actual contracting entities without filling gaps from an unrelated website.

Include an attachment reference that points to the original invoice. A reviewer should be able to select any row and find its source quickly. If a bank provides a required layout, map your working columns to that layout and retain the mapping. Do not assume that an attractive spreadsheet is automatically an accepted annex or that every optional working column belongs in the submitted form.

Represent one-to-many relationships explicitly

One customer can have several invoices, one invoice can have several receipts and one payout can cover several customers. Those relationships do not fit safely into a single amount field. Keep the invoice table stable and use linked allocation rows for receipts. When a payment covers several invoices, record how much is applied to each and check that the allocated total does not exceed the supported receipt.

Keep customer-level summaries as a view of the detailed data, not a replacement for it. If the bank asks about one export, the underlying invoice and payment trail should still be visible. Avoid collapsing unrelated customers into miscellaneous overseas clients; that hides information needed to understand a later refund, dispute or correction.

Review the schedule before and after format conversion

Check counts and currency subtotals in the working file before transferring information to the bank’s accepted format. After the transfer, compare the destination rows with the originals again. Formatting can change dates, truncate names or omit a final row. A PDF preview should be checked for clipped columns and headings that no longer match the information below them.

Freeze a copy of the exact schedule used for the submission and retain any later revisions separately. If an invoice is added after sending, ask about the correction or supplementary process rather than silently replacing the archived attachment. Keep the acknowledgement linked to the version actually sent. This makes later follow-up about a specific invoice much easier.

A fictional example

Three invoices belong to two customers: USD 800 and USD 600 for one, EUR 500 for the other. The schedule shows three rows and two currency subtotals. It never presents 1,900 as a meaningful combined currency amount.

Preparation checklist

Count invoice references after import.
Link every row to an original document.
Ask how the bank wants multi-client schedules attached.

Should I replace all customer names with the payment platform name?

No. Preserve the actual contractual parties and explain the platform’s role where relevant.

FICTIONAL WALKTHROUGH

Five invoices, three customers and two receipt routes

A fictional studio has three USD invoices for two customers and two EUR invoices for a third. It keeps five original invoice rows and two currency subtotals. One customer pays through a provider and another sends a direct transfer. The route is recorded without changing the customer identity.
A single provider payout covers two USD invoices. The preparer creates allocation rows connected to the payout reference and leaves a third USD invoice pending. A reviewer traces one row from each customer to its original document and checks the receipt allocations.
The bank’s confirmed schedule format uses fewer columns. The studio maps the required fields, reviews the rendered attachment and archives that exact version with the enquiry. Its richer working index remains available to explain fees, partial receipts or later corrections.

Your next step

See the fictional monthly example

Sources and scope

Sources reviewed 9 October 2026. The routines and fictional examples are editorial preparation suggestions. They do not confirm your bank’s acceptance, classification or transaction status.