Now eComm Inc Is the Seller

Part 12 of 16 · Behind the Buy Button

Mayan becomes the customer

Mayan uses eComm Inc's cloud service to run their print-management service. They also buy office equipment through eComm Inc's business storefront. The company that purchases printing machines from Sapiens Inc. now supplies that business with cloud services and office equipment.

We have not reversed every contract. We have added separate relationships. Reciprocal trade does not by itself establish barter, linked prices or permission to offset invoices.

The seller-side cheat sheet

Case	What Mayan is buying	What the platform role might be
Business storefront	Physical goods from the identified seller	Storefront, integration, selling or service role as specified
Cloud services	Contracted usage or access	Provider of its own services
Software marketplace	A third party's offering	Marketplace, billing or collection role under the relevant terms

A familiar checkout does not make these identical. AWS Marketplace's agreement structure distinguishes the underlying offering agreement from participants' agreements with AWS. The relevant terms, seller and billing entity must be checked for the particular transaction.

The shopping cart returns to the buyer's approval process

Suppose a Sapiens Inc. employee selects ten monitors at $300 each. The $3,000 cart represents a proposed purchase. In our fictional process it returns to Sapiens Inc. for approval before the order is placed.

That illustrates a pattern called punchout: shopping happens in a supplier catalog while purchasing approval remains in the buyer's system. AWS's procurement-integration documentation describes such an approval flow. The software integration is a bridge between organizations, not a reason to forget the buyer's authority.

If six monitors arrive first, Mayan's receiver should record six, leaving four open. Amazon Business's 2023 three-way-match launch announcement gives a public example of customer-side receiving and matching. It is evidence about a product for business customers, not Amazon's own internal accounts-payable procedure.

A PO reference is not a cloud spending brake

Assume Mayan authorizes $10,000 of cloud usage for a period but their systems consume $12,000. A PO number on the invoice does not erase the $2,000 difference.

AWS Billing documentation describes selecting a PO for invoice association using criteria such as entity, period, charge type and balance. It does not establish a hard consumption stop. The Marketplace integration documentation separately says usage estimates do not cap actual charges.

Mayan therefore needs both purchasing authority and operational usage controls. The contract determines the actual obligation; a budget overrun is a question to investigate, not automatic proof that the provider cannot bill the service.

A quantity of 1,200,000 may not mean a million products

The AWS integration documentation contains a revealing encoding rule. Certain usage or multiple-charge offers are represented as quantity-based Material lines priced at $0.01 per transport unit. The quantity preserves a monetary amount.

For an illustrative $12,000 arrangement, $12,000 ÷ $0.01 = 1,200,000 transport units. These are not necessarily licenses, users, print jobs or server-hours. The actual economic units come from the agreement and usage records.

This is why I would keep the original representation and its meaning together. A system can reconcile the invoice amount perfectly while producing an absurd “cost per license” because it misread the quantity field.

Customer payment and supplier remittance are separate events

Now assume a business customer pays $5,000 for Mayan's software through eComm Inc's marketplace. Under the fictional collection terms, the platform is authorized to receive that payment for Mayan. It later remits $4,800 after an assumed $200 fee.

Gross collection $5,000 = seller remittance $4,800 + assumed fee $200.

The customer's payment was $5,000, not $4,800. The platform fee is not Mayan's production cost. The timing of the customer's discharge and Mayan's bank receipt depends on the terms. AWS's seller terms, Payments section provide a scoped public example of authorized processing-agent collection and later remittance; our amounts are unrelated to its fees.

Mayan should reconcile the gross transaction, permitted deductions and cash received. eComm Inc should preserve each contractual role. An investor should distinguish money passing through a platform from revenue it earns. I, as a customer, should not have to pay a settled obligation again merely because the supplier's later remittance has not arrived; whether it is settled must be established from the actual authorized collection arrangement.

Continue the series

Previous: Buying Power, Renting Space, Committing Time. Next: One Transaction, Several Accounting Clocks. Return to the introduction and cheat sheet.

Evidence and method: public references were checked on October 18, 2026. The fictional scenarios, proposed controls and design conclusions are learning models, not claims about a real employer. Reported financial figures retain their stated measurement dates.