Marketplace Credit Notes: Which Period Does a Correction Belong To?

A marketplace credit note is a separate document that corrects an invoice already issued: the original stays as it is, and the correction points back to it.

A refund comes in May and concerns a sale from March. Your platform will do one thing with it: subtract the amount from the current settlement and move on.

For the flow of money, that is correct. For documents and for tax, it is the moment a question arises that most systems cannot answer: which period does this correction belong to?

The answer depends on the country, the year, and what exactly happened. Your tax advisor picks it.

This article is a map of mechanisms, and it makes one claim: your data model can close the road for your advisor before you get to ask them.

This article breaks down:

• What decides which period a marketplace correction belongs to?
• Which 2 kinds of correction must your system tell apart?
• Why does one refund produce at least 2 credit notes?
• Which tax treatment does a credit note carry?

Key insights

• The cause of a correction decides which period it belongs to, and the day you spot it decides nothing. The exact rule is national, so the answer changes with your country and your year.
• Two kinds have to be distinguishable in the data: an error at the source, where the document was untrue when it was issued, and a later event, where the world changed afterwards. A typed cause from a closed list is what makes that possible.
• Two corrections issued in the same month can belong to two different periods, and both still land in the same settlement, because the earlier one is already paid.
• One refund touches two relationships and so produces at least two credit notes: the seller's sale to the buyer, and your commission to the seller. Where you are the seller yourself, a third appears.
• A credit note carries the tax treatment frozen on the original order line, so that context has to be stored at the moment of sale: the treatment, the countries, the seller's status, and the rule applied.

What decides which period a marketplace correction belongs to?

The same event raises three independent questions about the period.

1. The document question: which date does the credit note carry?

A credit note has its own issue date. That date is always today's.

It also has to point unambiguously to the original document.

2. The tax question: in which return does the tax come down?

That one is for your advisor, and it is the subject of this article.

3. The result question: which month does the event belong to?

Your books settle this one. "Marketplace Ledger: Why Balances Must Match the Transfer" describes the mechanics of that layer: two dates on every entry, an entry nobody edits, a statement that adds up to the transfer.

This article stands on it and goes further, toward documents and tax.

Those three answers can point to different months, and that is not an error. The error is a system that knows only one of them.

What surprises people most often: in many legal systems, the cause decides which period a correction goes into. EU law says that on cancellation, refusal, a price reduction after delivery, or non-payment, the taxable amount goes down.

It attaches a condition: each member state sets the terms. The mechanism is shared; the period rule is national.

That is why you will not find one answer here: there is not one.

Which 2 kinds of marketplace correction must your system tell apart?

Tax guidance in many countries draws the same dividing line independently.

1. An error at the source

The document was untrue the moment it was issued: wrong commission rate, wrong amount, wrong buyer, an arithmetic slip. Nothing happened later.

It was wrong from the beginning. A correction like that is sometimes assigned to the period of the original document, because it straightens out a picture that was never true.

2. A later event

The document was true when issued, and then the world changed. The customer returned the goods, you granted a discount after the fact, an order was canceled after fulfillment.

A correction like that is sometimes assigned to the period in which the event happened, because only then did the ground for reducing the amount arise.

The date you spot it makes no difference. Two corrections issued on the same day can belong to different periods if one straightens out a mistake and the other reflects a refund.

It works the other way round too: a refund concerning March does not on its own belong back in March.

So this article makes one hard requirement of your system. Every correction has to carry a typed cause from a closed list.

Your advisor then gets data they can apply any rule to. That includes a rule that changes two years from now.

A text field called "reason for correction" looks like the same thing, but it is not: a year later, nobody will sort thirty thousand corrections by typos in a description.

Two corrections in the same month, 2 different periods: the worked example

A cart of €1,000, a commission of 12%, the seller gets €880, and you post €120 of revenue. The sale is in March, and the commission invoice for March goes out after the month closes.

Two things happen at once in May. The first: the customer returns that order.

The seller refunds €1,000 and gets €120 of commission back, so what they really lose is €880. This is a later event.

In March, everything was true. The second: somebody notices that this seller was charged 15% commission in March instead of the 12% in their contract, because the rate was typed in by hand.

On a single order, that is a difference of €30. This is an error at the source.

The commission invoice for March was untrue from the moment it was issued.

Both corrections land in the May settlement with that seller, because March is already paid and there is nowhere else for them to go. But for tax and for documents, they can belong to two different months, and your advisor settles which.

Your own job is narrower and doable: the system has to know that the first correction came out of a refund and the second out of a mistake in the rate, that both point at one specific March order and document, and that each carries its own event date and issue date.

If it does not know that, the corrections land in one bucket labeled "the May settlement." At that point, accounting has no way to show that the settlements line up with reporting requirements. The amounts are not wrong.

The problem is that a correction cannot be assigned to the period it concerns. That is where the manual work starts, every month, for every seller.

Why does one marketplace refund produce at least 2 credit notes?

A refund touches two independent commercial relationships. That is the easiest part to miss.

1. The seller's credit note to the buyer

The sale was theirs, so the correction of the sales document is theirs too. That holds even if your platform technically issued it in their name.

"Marketplace Invoicing: Who Issues Which Invoice, and When?" settles who issues which document.

2. Your commission credit note to the seller

The commission on a refunded order either disappears or stays. That is a separate commercial decision, described in "Who Keeps the Marketplace Commission on a Refunded Order?".

If it disappears and you have already issued the commission invoice for March, you have to correct your own document: a commission once calculated and invoiced cannot be "worked out one more time." In models where you are the seller to the customer, a third document appears, because you have two supplies instead of one, and the refund corrects both.

Two requirements: cheap at the start and expensive later on. A credit note has to point to the original unambiguously and in a machine-readable way: the number and the date in separate fields.

And a correction is always a new document: the system has to hold a separate "correction" object.

Which tax treatment does a marketplace credit note carry?

The most common design mistake in this layer is a quiet one: the system generates a correction from the tax configuration it has to hand, which is today's. But a correction reverses the effect of one specific past transaction, so it has to carry that transaction's tax treatment.

• Did the rate change between March and May? The correction goes at the March rate.
• Did the seller's registration status change? What counts is the status on the day of delivery.
• Did you change your commission grid? A correction to a March commission goes at the March grid.

The consequence for the data model is hard. The tax context has to be frozen on the order line at the moment of sale.

That means the treatment, country of dispatch, country of delivery, seller's status, and the rule applied. The correction reads that context instead of working it out again.

It is the same principle for which the exchange rate is frozen on an accounting entry, applied to tax.

What changes when the accounting period is closed, and the invoice cannot be withdrawn?

Once a period is closed, you no longer post into it. You post into the current one and point the entry at its source period.

With documents, it is tighter still. In countries that have introduced mandatory reporting of invoices into the tax administration's system, a document once issued and accepted stops being yours: you cannot withdraw or delete it, and the only route to a fix is a new credit note, sent through the same channel and pointing at the original document.

"Marketplace E-Invoicing: What Changes When You Invoice for a Seller?" develops what that changes in the design of a marketplace.

It means three things at once. A correction is an accounting event and an integration event.

It travels the same channel as an invoice, with the same validation rigor and rejection handling. Issuing documents in somebody else's name has a contractual condition.

Self-billing requires a prior agreement between the parties and an acceptance procedure, so if you want to issue and correct for your sellers, it has to be in the contract before the first document. And corrections have a time window, of different lengths in different countries.

That feeds straight into your returns policy: a generous promise can produce a document that can no longer be settled.

What do marketplace credit notes change about your other decisions?

1. Reporting and correcting a report are two different capabilities

Where transactions reach the administration as they happen, a correction is a separate reporting event. Market observation suggests that more systems can produce a report than can fix one.

The question "what does a correction to a report we already filed look like" separates the two in a minute.

2. If the platform is the taxable person on part of the flows, the correction is yours

Deemed supplier rules can move the tax obligation onto you on a sale you do not make under civil law. The refund then corrects your own return and your own cycle, including under special schemes.

"Online Marketplace VAT: When Does the Platform Become the Deemed Supplier?" covers when that happens.

3. Expected refunds touch revenue before they happen

In financial reporting, a sale with a right of return is recognized with an allowance for how much you expect to give back, and the estimate is updated at every balance sheet date. Your refund data is therefore needed as a time series too.

What counts as your revenue is settled by the chapter on marketplace revenue recognition. Where the amounts come from is settled by "Marketplace Refunds: Who Pays for Them and Out of What?".

How do you check marketplace credit notes with an advisor and a vendor?

1. Questions for your tax advisor

1. "A refund in May against a sale from March. In the return for which period does the tax come down, and what does that depend on?" Ask for the rule behind the answer.
2. "In our case, how does a correction caused by a mistake differ from a correction caused by a refund?" If the answer is "by period," you have the list of cause types your system has to know.
3. "What conditions do I have to meet for a correction to reduce the tax, and which of them is an event I have to record?" This is where requirements like confirmation of receipt come out.
4. "How far back can I correct, and does that depend on the kind of correction?" The answer sets your returns policy.

2. Questions for your platform vendor

1. "Show me a correction for a refund and a correction for a wrong commission rate side by side. How do they differ in the data?" If they differ in nothing but the amount and the description, the system cannot tell them apart.
2. "Where is the reference to the original document, and is it machine-readable?"
3. "Where does a correction take its tax treatment from: the order, or today's configuration?" Ask for a test. Change the rate and generate a correction to an old order.
4. "What happens when a correction concerns a period for which we have already issued a commission invoice?" You want to hear "a credit note to that invoice is created." If you hear "we recalculate the balance," it cannot.

Which mistakes do operators make about marketplace credit notes?

1. A correction done as an edit of the document

Convenient right up to the moment the document leaves your system. After that, it is not a fix.

It is a divergence between your version and the one the other party and the administration hold.

2. One bucket called "the current settlement"

The amounts add up, and the assignment is missing. This is where accounting teams building their own settlements next to the platform come from: a cost your business case does not contain.

3. The reason for a correction kept as a text field

It looks like data, and it is not data.

4. Recalculating a correction against today's configuration

Flawless until the first change of a rate or a commission grid.

5. A returns policy set without asking about the correction window

The decision is taken in marketing and comes back in finance.

What do you still have to settle yourself about marketplace credit notes?

This is a map of mechanisms. Five things to confirm with a tax advisor and with a lawyer, for your own country and year, before you fix the rules in your system:

1. Which period each kind of correction belongs to in your case. The rule is national, and it can differ between ordinary accounting and special schemes.
2. What formal conditions have to be met for a correction to reduce the tax? Some legal systems require an event on the recipient's side, and you have to be able to record it.
3. Who issues the correction to the sales document in your model, and on what contractual basis? If you issue in your sellers' name, the agreement and the acceptance procedure are a job for a lawyer.
4. What a correction looks like in a mandatory e-invoicing channel and in transaction-level reporting. That includes what happens when a credit note is rejected.
5. How far back you are allowed to correct, and whether the same window covers refunds, complaints, and mistakes. That is the boundary your after-sales policy has to fit inside.

Our own claim is narrower and depends on none of those answers: the data has to let you answer both ways. The type of cause, the event date, the document date, the reference to the original document, a frozen tax context.

With those in place, your advisor applies whichever rule holds and changes it when the law does. Without them, what you hear is that it has to be worked out by hand.

Summary: Which period does a correction belong to?

The one your advisor picks, from the cause of the correction and from the rules of your country and your year. Your own part is narrower, and it is the part that has to exist first: a typed cause, an event date, a document date, a reference to the original, and the tax context frozen at the moment of sale.

Ask a vendor to show a refund correction and a wrong-rate correction side by side, on screen. Talk to a marketplace expert if you want to check whether your corrections carry a typed cause.

Frequently asked questions on marketplace credit notes

What is a credit note on a marketplace?

A credit note is a separate document that corrects an invoice already issued, and on a marketplace one refund usually calls for more than one of them. The seller's sale to the buyer and your commission to the seller are two relationships, so each carries its own correction. The original documents stay as they are and the credit notes point back at them.

Which period does a credit note belong to?

It follows from the cause of the correction, and the precise rule is set nationally. A correction that straightens out a document that was untrue when issued is often assigned to the period of that document. A correction that reflects something which happened later, such as a return, is often assigned to the period of that event. Confirm both with a tax advisor for your country and your year.

Can a marketplace edit an invoice instead of issuing a credit note?

Once the document has left your system, the edit stops being a fix and becomes a divergence. Where invoices are reported into a national system, a document that has been accepted cannot be withdrawn at all, and the only route to a correction is a new credit note through the same channel. Your platform therefore has to hold a separate correction object, and leave the invoice itself untouched.