Which payments to customers are really a discount on your revenue?

An implementation checklist.

1. 1.Link the vendor record to the customer record. The whole analysis starts with a fact most ledgers cannot state: this party we are paying is also a party that buys from us. Accounts payable and accounts receivable usually hold that entity twice, under different identifiers, maintained by different teams. One party identity, with both subledger keys hanging off it, turns an interpretive question into a query.
2. 2.Extend the same idea one step down the chain. The project is about payments made on behalf of a customer and payments to a customer of a customer, so the party record needs a role in the revenue chain rather than a simple customer flag. Direct customer, reseller in the distribution chain, customer of a customer, and unrelated supplier are four different answers with three different consequences.
3. 3.Attach each payment to the revenue it relates to. ASC 606-10-32-27 recognises the reduction at the later of the transfer of the related goods or services and the promise to pay, so a payment without a link to a contract cannot be timed correctly even when its classification is obvious. Carry the contract identifier on the payment rather than inferring it later from an account code.
4. 4.Record the basis on which the payment is owed. An explicit contract clause, an implicit promise arising from customary business practices or a published policy, an in-substance price concession, or an ordinary purchase are the categories that matter under the recommended framework. Recording the basis at the time forces the question to be asked while the answer is still known.
5. 5.Keep the evidence for an implicit promise, because it lives outside the contract. The Task Force draft points at customary business practices, published policies and specific statements. In practice that means campaign pages, published incentive terms, partner communications and the reports you already share with the customer. Those are marketing artefacts today and accounting evidence under the proposal.
6. 6.Hold a fair value, and the working behind it, for anything claimed as distinct. The fair value ceiling in ASC 606-10-32-26 is where an expense classification is won or lost, and an entity that cannot reasonably estimate fair value reduces the transaction price by the whole payment. Quotes, rate cards and comparable purchases retained at the time are cheap; reconstructing them in an audit is not.
7. 7.Split rather than round. Where a payment exceeds the fair value of what was received, the excess reduces the transaction price while the rest is an ordinary purchase. Systems tend to force one classification per payment, so build the split as a first-class outcome rather than a manual journal someone remembers to post.
8. 8.Run one exception query before each close. Payments to parties in the revenue chain with no contract linked, unlinked vendor and customer records for the same legal entity, distinct claims with no fair value evidence, incentives with no recorded basis, and published incentive policies with no payments mapped to them are the gaps. While that list has entries, the split between revenue and operating expense rests on judgement nobody has written down.

Failure modes, framed so you can plan around them.

• Letting the payment method decide the accounting. A payment that leaves through accounts payable looks like a cost, and the system that raised it reinforces that impression: a trade promotion tool books promotion spend, a marketing platform books marketing spend, a rebate engine books a rebate. None of those systems asks whether the payee is on the buying side of your own revenue chain. The remedy is not to distrust the tools but to give them one shared party identity, so the question is answered once rather than assumed four times.
• Assuming a contract clause is the only trigger. The narrower reading, that only a contractually required payment to a customer of a customer counts, is exactly the one the project is aimed at. The recommended framework brings in an implicit promise that can arise from customary business practices, published policies or specific statements. A team that only searches its contract repository will miss payments that are promised on a campaign page.
• Treating a claim of distinctness as self-evident. It is easy to call a co-op advertising reimbursement a purchase of advertising and move on. The guidance asks whether the good or service is distinct and what its fair value was, and where fair value cannot be reasonably estimated the entire payment reduces the transaction price. A conclusion recorded without evidence is a conclusion that will be revisited by someone less sympathetic.
• Ignoring the excess. Where a payment exceeds the fair value of what came back, only the excess reduces the transaction price. That split is genuinely useful reporting, and it is also the part most likely to be skipped because the payment is one row in one system. Designing for a split payment now avoids a class of adjustment later.
• Timing the reduction to the cash. The recognition point is the later of the revenue on the related transfer and the promise to pay, and the promise can precede the payment by a long way, including where it is conditional on a future event. Booking the reduction when the money moves is a defensible-sounding habit that produces the wrong period.
• Waiting for the exposure draft before finding the population. Every alternative the Task Force considered broadens the current scope, which means more payments come inside it whichever way the Board goes. The useful work, linking parties and attaching payments to contracts, is identical under all three. Doing it now converts a future reassessment into a filter over records you already keep.
• Assuming this is a problem for marketplaces only. Platform and marketplace models are where the scoping challenge is most obvious, and the Issue Summary says so. It also says the revised guidance would apply to all entities making payments to customers of a customer, and offers the example of a seller’s real estate agent sharing part of its commission with a buyer. Consumer goods, software, medical devices and franchising all have their own version.
• Expecting an election to soften the landing. The recommendation is that the guidance apply to all entities and be required rather than optional, because an election would not deliver the consistency the project exists to create. Planning on the basis that a private company or a smaller filer will get a carve-out is planning for something nobody has proposed.

What this asks of the data model.

• One party, many subledgers. A legal entity that both buys from you and receives money from you is one party with an accounts receivable key and an accounts payable key, not two unrelated records that happen to share a name. Everything else here depends on that link existing and being maintained.
• The role in the revenue chain is a field. Direct customer, reseller within the distribution chain, customer of a customer, and unrelated supplier are distinct values with distinct consequences, and the one that is newly interesting is the third. Where a party buys from your customer rather than from you, record who it buys from.
• Every payment names the revenue it relates to. Without a contract link the timing rule cannot be applied, and the population cannot be assembled for review. A null link is itself informative, because it says this payment has no revenue consequence to consider.
• The basis is recorded, not inferred. Explicit clause, implicit promise, in-substance price concession, or ordinary purchase. Recording which one applies, and why, at the time of the payment is the difference between a documented judgement and a reconstruction.
• Evidence for an implicit promise is captured where it is created. Customary business practices, published policies and specific statements live in marketing systems, partner portals and campaign records. Referencing them from the payment record keeps them findable once the campaign is over.
• Fair value is a number with a source. Anything claimed as a purchase of a distinct good or service carries the fair value received and the basis for it, so that the excess over fair value can be calculated rather than argued.
• Presentation is an outcome, not an input. Reduction of the transaction price, operating expense, or a split between the two follows from the fields above rather than from the system that raised the payment or the budget it was drawn against.
• Completeness reduces to one exception query. Unlinked parties, missing contract links, unevidenced distinctness claims, unsplit excesses, incentives without a basis, and policies with no payments mapped to them are the exception list, run before a period is relied on rather than discovered in review.

The evidence to keep.

• The party register, showing each legal entity that both receives payments and sits somewhere on the buying side of the revenue chain, with its accounts receivable and accounts payable identifiers linked and its role recorded.
• The payments population, showing for each outgoing payment the payee, the role of that payee, the revenue contract it relates to, the basis on which it is owed, and the presentation applied, which is the population any test of revenue classification has to start from.
• The promise evidence, showing for each payment treated as implicitly promised the customary business practice, published policy or specific statement relied on, retained as it appeared at the time rather than as later described.
• The fair value working, showing for each payment claimed as a purchase of a distinct good or service what was received, its fair value, the source of that estimate, and the excess treated as a reduction of the transaction price.
• The timing basis, showing for each revenue reduction the date revenue was recognised on the related transfer and the date the consideration was paid or promised, evidencing recognition at the later of the two.
• The recorded scope position, stating how the entity evaluates payments made on behalf of a customer and payments to a customer of a customer, together with evidence that the systems implement the position as stated.
• The exception query output, ideally empty, listing unlinked parties, payments with no contract, distinctness claims with no fair value evidence, unsplit excesses, incentives with no recorded basis, and revenue reductions recognised early.

Questions worth asking in your own review.

• Can we produce, today, a list of every party we paid in the last quarter that also buys from us, directly or through one of our customers?
• Does any system we run hold the fact that a given accounts payable vendor and a given accounts receivable customer are the same legal entity?
• For each incentive programme we fund for end users, where is the promise recorded, and would we call it explicit or implicit?
• When we classify a payment to a customer as buying something distinct, what evidence of fair value do we retain, and for how long?
• Have we ever split a payment between an expense and a reduction of the transaction price, and can our systems post that split without a manual journal?
• Do we recognise revenue reductions at the later of the related transfer and the promise to pay, or when the payment clears?
• If the exposure draft lands in the fourth quarter and asks for modified retrospective application, which open contracts would we have to reassess, and could we find their payments?
• Who owns the answer to all of this: revenue accounting, the trade promotion team, or nobody in particular?

What this adds up to.

The accounting question here is narrow. How far along your own distribution chain does the idea of consideration payable to a customer reach, and what makes a payment count when no contract requires it? The Task Force has put a workable answer to the Board: an explicit or implicit promise, or a payment that is in substance a price concession the customer reasonably expects you to fund. An exposure draft is expected in the fourth quarter of 2026.

The operating question is wider and more useful. A company that can produce, on demand, the list of every party it pays that also sits on the buying side of its revenue, with each payment attached to a contract and a reason, has solved something bigger than a scope clarification. It can say what its revenue actually is net of what it hands back. It can show an auditor why a payment sits in operating expense rather than against revenue, and back it with a fair value that was recorded at the time. It can price a promotion knowing which line it will land on.

If there is one place to start before the exposure draft arrives, it is the party link. Run your accounts payable vendor master against your accounts receivable customer master and find the legal entities that appear in both. That list is usually longer than people expect and almost never maintained. Everything else in this article is built on top of it, and none of it depends on knowing which alternative the Board picks, because all three widen the scope and all three need the same facts. That is an unusually comfortable position to be in a quarter ahead of a proposal.

Sources.

• FASB, EITF Issue Summary No. 2, Consideration Payable to a Customer, Issue Date June 2026, prepared for the EITF meeting of 23 June 2026, Issue Stage Initial Deliberations. Downloaded and read directly, page by page, rather than through a summary. Source for the origin of the issue, namely that on 30 January 2026 the Emerging Issues Task Force received an agenda request from Deloitte relating to scope considerations about when payments made on behalf of customers, or to customers of customers, should be accounted for as consideration payable to a customer, and that the EITF Agenda Committee added the issue at its March 2026 agenda committee meeting. Source for the three alternatives put to the Task Force, for the proposed paragraphs 606-10-32-25B and 606-10-32-25C drafted under each, for the two illustrative examples of a platform company and its end-user credits, for the Lead EITF Member recommendation of Alternative A, for the view that the recommended solution should apply to all entities and be required rather than elective, and for the discussion of prospective, modified retrospective and full retrospective transition together with the observation that each alternative broadens the current scope of the guidance.
• FASB, Technical Agenda Overview, revised 9 September 2026. Downloaded and read directly. Source for the project status as at the time of writing: Consideration Payable to a Customer appears on the technical agenda with a next milestone of Exposure Draft and an expected date of the fourth quarter of 2026. The same page records the neighbouring revenue-adjacent projects and shows that the Emerging Issues Task Force itself currently has no open projects.
• EY, Financial reporting developments: Revenue from contracts with customers (ASC 606), September 2026 edition. Downloaded and read directly rather than through a summary. Source for the codified text of ASC 606-10-32-25 through 32-27 quoted here, including the three listed forms of consideration payable to a customer, the requirement to account for it as a reduction of the transaction price and therefore of revenue unless the payment is in exchange for a distinct good or service, the fair value ceiling and the treatment of any excess, and the recognition timing at the later of the transfer of goods or services and the promise to pay. Also the source for the recorded status that in August 2026 the FASB decided to add this project to its technical agenda and is expected to issue an exposure draft applying to all entities in the fourth quarter of 2026, for the June 2026 EITF recommendation as EY records it, and for the worked examples of slotting fees, cooperative advertising, buy downs and price protection, coupons and rebates, pay to play arrangements, and purchases of goods or services from a party that is also a customer.
• FASB, Share-Based Consideration Payable to a Customer, recently completed project page. Background for the separate and already finished piece of work on the same paragraph of the Codification, which added ASC 606-10-32-25A and the implementation guidance at 606-10-55-88A through 55-88C. It is useful here as context for how the Board has been working through this area in pieces, and as a reminder that the current project deals with scope rather than with the form of the consideration.
• PwC Viewpoint, Revenue Transition Resource Group reference material on consideration payable to a customer and on payments to customers. Background for the transition resource group discussions the Issue Summary refers to, including the point that the group agreed a payment to a customer of a customer would be a payment to a customer where the entity has a contractual agreement with its customer to provide that consideration, which is the narrower position the current project is intended to extend.
• RevenueHub, Consideration Payable to a Customer. A practitioner explainer of the same guidance, useful for the ordinary shapes these payments take in the field and for the distinction between a payment that buys something distinct and a payment that is in substance a price reduction.
• Grant Thornton, FASB clarifies accounting for share-based consideration payable to a customer, August 2025 snapshot. Background on the completed share-based strand of this guidance, read as context rather than as a source for the scope question this article is about.

The origin of the issue, the three alternatives, the proposed paragraphs 606-10-32-25B and 606-10-32-25C, the illustrative platform examples, the recommendation of Alternative A, the position that the guidance should apply to all entities and be required, and the transition discussion were read directly from the EITF Issue Summary prepared for the meeting of 23 June 2026, which was downloaded and read page by page rather than through a summary. The project status, namely an exposure draft expected in the fourth quarter of 2026, was read directly from the FASB technical agenda overview revised on 9 September 2026 and corroborated by the September 2026 edition of EY’s revenue publication, which records that the Board decided to add the project in August 2026. The codified text of ASC 606-10-32-25 through 32-27 quoted here is reproduced from that same publication. Everything described as recommended, proposed or expected is not yet authoritative: no exposure draft had been issued at the time of writing, and the requirements in force are unchanged. No embedded posts from X appear here, because no public post on this project could be verified as current, relevant, and authentic at the time of writing, and an unverified embed is worse than none. Nothing here is accounting, tax, or legal advice for a specific company, and the names, amounts and dates in the worked record are placeholders for shape rather than real values.