> ## Content Index > Fetch the complete content index at: https://abundance.alloconomy.com/llms.txt > Use this file to discover other available public pages before exploring further. # I Bought a Book. What Had to Be Promised First? - URL: https://abundance.alloconomy.com/alloconomy/behind-the-buy-button/ - Published: 2026-10-19T07:34:52.000Z - Updated: 2026-10-22T22:19:00.000Z - Description: The cast, the cheat sheet, and the whole commercial system. - Author: Sathya Narayanan - Tags: Alloconomy, Supply Chain, Commerce, Behind the Buy Button, #series-introduction, #Import 2026-10-18 23:22 Supply Chain · Sixteen essays Behind the Buy Button Complete reading path · You are in Part 1 of 16 1. Part 1 **I Bought a Book. What Had to Be Promised First?**Current essay The cast, the cheat sheet, and the whole commercial system. 2. Part 2 [Maya Sells to eComm Inc. Maya Also Sells Through eComm Inc.](https://abundance.alloconomy.com/alloconomy/commerce-who-is-selling-to-whom/) Retail vendors, marketplace sellers, custody and direct fulfillment. 3. Part 3 [The Purchase Order Begins Before the Purchase Order](https://abundance.alloconomy.com/alloconomy/commerce-before-the-purchase-order/) Need, supplier identity, sourcing, approval and changing commitments. 4. Part 4 [Sent, Received, Accepted: Three Different Claims](https://abundance.alloconomy.com/alloconomy/commerce-sent-received-accepted/) Order lines, shipment assertions, receipt evidence and message status. 5. Part 5 [The $140 Disagreement Inside One Invoice](https://abundance.alloconomy.com/alloconomy/commerce-the-140-dollar-disagreement/) Two-, three- and four-way matching, disputes and settlement. 6. Part 6 [The Price After the Price](https://abundance.alloconomy.com/alloconomy/commerce-the-price-after-the-price/) Rebates, credits, working capital and realized supplier economics. 7. Part 7 [How Do You Receive an Hour of Work?](https://abundance.alloconomy.com/alloconomy/commerce-how-do-you-receive-an-hour/) Labor, maintenance and professional services need their own evidence. 8. Part 8 [Software Is a Promise Over Time](https://abundance.alloconomy.com/alloconomy/commerce-software-is-a-promise-over-time/) Access, usage, licenses, digital rights and renewal decisions. 9. Part 9 [A Printing Machine Is Not Yet Printing Capacity](https://abundance.alloconomy.com/alloconomy/commerce-a-machine-is-not-yet-capacity/) Manufacturing plans, advances, assets and readiness for use. 10. Part 10 [When the Project Changes, What Exactly Changed?](https://abundance.alloconomy.com/alloconomy/commerce-when-the-project-changes/) Scope, RFIs, approved changes, progress claims and retention. 11. Part 11 [Buying Power, Renting Space, Committing Time](https://abundance.alloconomy.com/alloconomy/commerce-power-space-and-time/) Electricity, financial energy settlements and leases. 12. Part 12 [Now eComm Inc Is the Seller](https://abundance.alloconomy.com/alloconomy/commerce-the-platform-becomes-the-seller/) Business purchasing, cloud billing and marketplace collection. 13. Part 13 [One Transaction, Several Accounting Clocks](https://abundance.alloconomy.com/alloconomy/commerce-one-transaction-several-clocks/) Commitments, accruals, cash, assets and financial-statement scale. 14. Part 14 [A System That Can Remember Why](https://abundance.alloconomy.com/alloconomy/commerce-a-system-that-remembers/) Linking documents, quantities, time, corrections and independent evidence. 15. Part 15 [Safety Before Speed: What a Green Tick Cannot Approve](https://abundance.alloconomy.com/alloconomy/commerce-safety-before-speed/) Payment authority, supplier changes, duplicates, incentives and AI limits. 16. Part 16 [Follow the Promises Back to My Book](https://abundance.alloconomy.com/alloconomy/commerce-follow-the-promises-home/) A worked capstone and the bridge to the inbound and outbound series. **Illustrative examples. Public sources. Personal views.** I am Sathya Narayanan, writing in a personal capacity as I learn in public. The views, interpretations and teaching models are my own; they do not represent my employer or any other organization and carry no employer approval or endorsement. No confidential, proprietary or nonpublic employer information is used. Factual background comes only from publicly available sources. Maya of Stories Inc, the book vendor; Mayan of Sapiens Inc, the printing-machine supplier; and eComm Inc, the ecommerce company, are fictional teaching characters and companies. I appear as the customer in imagined scenes, not as a report of my actual purchases. These scenes do not describe any real company or its internal systems. The cases are separate teaching examples, not one continuous ledger. Scenario amounts, rates, terms and policies are illustrative assumptions unless expressly identified as dated public facts. Actual contracts, regulations, operations and economics require case-by-case analysis. **Visual guide: the steps and the records they create** [Open the buying and selling graph and quick definitions →](https://abundance.alloconomy.com/alloconomy/behind-the-buy-button/#buyer-seller-construct-map) See the industry names for PO, sales order, ASN, receipt, invoice and payment, with the steps that create or update each record. Companion maps: [Inbound receiving](https://abundance.alloconomy.com/alloconomy/before-the-shelf/#buyer-seller-construct-map) · [Customer fulfillment](https://abundance.alloconomy.com/alloconomy/from-click-to-doorstep/#customer-fulfillment-construct-map) *Part 1 of 16 · Behind the Buy Button* ## I came for a book Imagine me, Sathya Narayanan, sitting at the kitchen table with a book I have just ordered. The title is *Making Things Work*. I paid $30 on eComm Inc, our fictional large-scale commerce platform. I open the parcel, check the edition, and notice Stories Inc. on the publisher's page. My purchase looks simple. Maya made a book. I wanted it. eComm Inc helped it reach me. Then I ask a question that makes the picture less simple: **who actually sold this book to whom?** Did Maya sell it to eComm Inc, which sold it to me? Did she sell it directly to me through eComm Inc's marketplace? Who owned it while it sat on a shelf? If eComm Inc also bought a printing machine from Mayan, would that purchase work like buying the books? I am writing this series to learn how to ask those questions properly. This is my attempt to make a complicated commercial system understandable, starting with something I can hold in my hands. I will distinguish what public sources say from the examples I construct and the conclusions I draw. [![Part 1: the whole system. Agreement → evidence → claim → recognition → settlement Fictional teaching model.](https://storage.ghost.io/c/f5/a9/f5a9f801-5a10-44d6-b07c-6658660be1a9/content/images/behind-the-buy-button/figures/part-01.png)](https://storage.ghost.io/c/f5/a9/f5a9f801-5a10-44d6-b07c-6658660be1a9/content/images/behind-the-buy-button/figures/part-01.png?ref=abundance.alloconomy.com) Who promises what to whom? MAYA · STORIES INC. — Book vendor — Books and publishing rights; MAYAN · SAPIENS INC. — Machine supplier — Equipment, software and services; eComm Inc — Buyer + platform — Distinct purchasing and selling roles; SATHYA NARAYANAN — Author + customer — Imagined scenes; personal views. Relationship map, not a physical route or a dollar allocation. Fictional example; see the nearby table and prose for an accessible explanation. [View the full-size diagram →](https://storage.ghost.io/c/f5/a9/f5a9f801-5a10-44d6-b07c-6658660be1a9/content/images/behind-the-buy-button/figures/part-01.png?ref=abundance.alloconomy.com) ## Meet the people and the business roles **Maya runs Stories Inc., the book vendor.** She publishes and produces *Making Things Work*. Her business can sell books to a retailer or sell them through a marketplace. Stories Inc. also holds the book’s publishing and digital rights. **Mayan runs Sapiens Inc., the sophisticated printing-machine supplier.** Sapiens Inc. supplies the machines that print books. In our teaching examples, it also offers related maintenance work and print-management software under separate agreements. Maya and Mayan are different people running different businesses; their orders, invoices and obligations must remain distinct. **eComm Inc is our fictional ecommerce company.** Its retail business buys and resells merchandise. Its marketplace connects merchants with customers and can provide services. Its operations team buys the equipment and work that keep the business running. Its cloud service sells business services. These labels describe roles; a real transaction must identify the actual contracting legal entities. **I am Sathya Narayanan, the author and customer in the imagined scenes.** I inspect the seller's name, compare the order with what arrives, and follow a refund when something goes wrong. These scenes are not claims about purchases I actually made. Amazon's public documentation is one useful reference because it exposes several distinct relationships. For example, its [retail vendor interface](https://developer-docs.amazon/sp-api/docs/vendor-retail-procurement-orders-api?ref=abundance.alloconomy.com) describes purchase orders and supplier acknowledgements. The fictional model will let us explore the underlying ideas without claiming to reveal any company's internal process. ## Why this matters beyond the purchasing department For Maya and Mayan, a sale is useful only if their businesses can deliver it, explain what they are owed, and survive the wait for cash. A lower price can be tolerable with reliable volume; a seemingly generous contract can become expensive if disputes consume their time. For an eComm Inc employee, the problem is to buy what the business needs, verify what happened, and pay the right obligation. A warehouse count cannot certify software availability. A software login cannot certify that an implementation project worked. For me as a customer, seller identity affects whom I approach about the book and which promise I am asking someone to honor. For an investor, receipts, revenue, liabilities, profit and cash are different quantities. Understanding the commercial relationship helps explain the numbers; it does not establish whether a stock is attractive. ## The cheat sheet I want beside me | Question | Record or idea that helps | What it does not prove | | ------------------------------ | ------------------------------------------------- | ----------------------------------------------------------------- | | Who is buying from whom? | Contract and named parties | A platform logo does not identify every seller | | What did the buyer authorize? | Approved request, order or agreement | A forecast is not a supplier commitment | | What did the supplier promise? | Acknowledgement and effective terms | An order sent is not an order accepted | | What happened? | Count, service record, usage or progress evidence | A supplier's report is not automatically independent confirmation | | What met the requirements? | Inspection or acceptance decision | Arrival alone does not prove quality | | What is being claimed? | Invoice, credit or payment request | An invoice is not proof of completed performance | | What belongs in the accounts? | Recognition under the applicable policy | The arrival of a document is not the only relevant date | | What was settled? | Confirmed cash and its allocation | Payment initiation is not final settlement | | What remains? | Open quantities, disputes, rights and renewals | A closed order does not erase every continuing obligation | The familiar sequence is **agree → order → perform → check → bill → settle → reconcile**. It is a useful first sketch. It is not a promise that every event happens once, in that order. An advance can precede delivery. An invoice can follow work by a month. A credit can arrive after payment. ## One example before we separate the branches Suppose eComm Inc orders 100 books from Maya at $20 each. The order value is: **Order value = quantity × unit price = 100 books × $20 per book = $2,000.** That is the value of this assumed order. It is not yet proof of $2,000 delivered, accepted, expensed or paid. If Maya sends 60 books, eComm Inc counts 58, and two await inspection, all four numbers belong in the story. We will work through the disagreement rather than replace those numbers with one reassuring status. The same question changes shape when eComm Inc buys Mayan's $100,000 printing machine. The business needs a working production system, not merely evidence that a large object arrived. When it buys Sapiens Inc.’s software, it needs the agreed access and service over time. When it buys maintenance labor, it needs evidence that the contracted work happened. ## Three series, with a clear boundary **This is the Procure-to-Pay series within Supply Chain Management in hyperscale ecommerce.** We follow a business purchase from need and sourcing through authorization, supplier commitment, performance evidence, invoice reconciliation and payment. We will touch a shipment when it changes a claim, obligation or accounting question. Equipment and services show why receiving and acceptance need different evidence for different purchases. [**Before the Shelf**](https://abundance.alloconomy.com/alloconomy/before-the-shelf/) is the inbound inventory supply-chain series: preparation, transport, appointments, receiving and usable stock. [**From Click to Doorstep**](https://abundance.alloconomy.com/alloconomy/from-click-to-doorstep/) is the outbound finished-product-to-consumer series: the sale and delivery promise, fulfillment, delivery, recovery and returns. Each series has its own opening and reading path. These are connected views, not three stages that must finish in sequence. Supplier payment can remain open while inventory is already usable or a customer order is being fulfilled. We use the same cast across the collection, with distinct worked transactions. Here, eComm Inc buys Mayan's machine for a separate print-on-demand operation. In the inbound case, Mayan supplies a machine to Maya at Stories Inc. The book quantities, prices and costs in the three series are separate teaching cases; they must not be added together as one purchase or one ledger. Within this series, Parts 2–6 unpack merchandise relationships and their economics. Parts 7–11 examine labor, software, machines, projects, energy and leases. Parts 12–15 turn the relationship around and examine billing, accounting, data and safety. Part 16 brings the examples back together. The complete reading path above links each essay; this introduction is the only series entry on Home and the Supply Chain section. ## What I hope to learn in public I began with the picture of a book moving from Maya to me. I now need a second picture: who promised what, what evidence exists, and what remains unresolved. The physical journey and the commercial relationship interact, but neither fully explains the other. My working question for the series is simple enough to carry into a meeting: **what does this record actually prove, and what would I still need to know?** ## The buyer–seller map: steps and the records they create If I open a purchasing system, I want to recognize its nouns as well as its verbs. **Ordering** is a step. A **purchase order (PO)** is a record. **Matching** is a check across records. It does not turn them into one document. The backbone here comes from industry message standards: order, order response, despatch advice, receiving advice, invoice and remittance advice. Internal business systems add their own records around those exchanges. [GS1 describes that message chain](https://www.gs1.org/standards/edi/solutions?ref=abundance.alloconomy.com); [OASIS UBL defines the corresponding business documents](https://docs.oasis-open.org/ubl/UBL-2.4.html?ref=abundance.alloconomy.com). The map is my simplified teaching synthesis, with system-specific names identified below. Here, eComm Inc buys books from Maya’s Stories Inc. The cards name **the step, the record and the responsible party**. Arrows show selected references or work handoffs, not proof of completion or a universal creation sequence. One record can lead to several later records. This is the main merchandise path; services and equipment need additional evidence. [![Buying and selling record graph: PO to seller sales order, branching to order response, outbound delivery and invoice. ASN informs inbound delivery; goods receipt informs receiving advice and invoice matching; payment links to remittance advice. Every record card names its process step and party.](https://storage.ghost.io/c/f5/a9/f5a9f801-5a10-44d6-b07c-6658660be1a9/content/images/2026/10/supplier-constructs.png)](https://storage.ghost.io/c/f5/a9/f5a9f801-5a10-44d6-b07c-6658660be1a9/content/images/2026/10/supplier-constructs.png?ref=abundance.alloconomy.com) Step names appear above the digital record names. The tables below provide the same vocabulary in text, explain what is created or updated, and link to the public sources. This is a simplified teaching graph. Tap or click to enlarge. ### Ordering and delivery: whose record is it? | Step | Digital record created or updated | What I should recognize | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Ordering** | Buyer creates a **purchase order (PO)**. | Items, quantities, prices and requested delivery terms. Each order line has its own identity. | | **Order entry** | Seller creates a **sales order (SO)**. | The seller’s internal customer-order record. Its number is different from the buyer’s PO number; references connect them. | | **Order confirmation** | Seller sends an **order response**, also called an **order acknowledgement** or **order confirmation** in trading workflows. | It states acceptance, rejection or proposed changes. A technical message-delivery acknowledgement alone does not accept the order. | | **Outbound delivery creation** | Seller creates an **outbound delivery** in systems such as SAP. | A logistics document for the lines to fulfill. It can exist before the goods leave. | | **Shipment notification** | Shipper sends a **despatch advice**, commonly an **advance shipment notice (ASN)**. | Declared contents, quantities and order/package references. It is the sender’s statement. | | **Inbound delivery creation** | Buyer creates an **inbound delivery**, for example from the supplier’s notice in SAP. | What the destination expects to receive. This is a different record from both the ASN and the eventual receipt. | | **Goods receipt posting** | Receiver creates a **goods receipt document**; SAP records the posting in a **material document**. | What was received against which order or delivery. Receipt does not by itself establish saleable stock. | | **Receipt notification** | Receiver may send a **receiving advice**; UBL calls its document **ReceiptAdvice**. | The receipt and discrepancies communicated back to the other party. The internal receipt and external message serve different audiences. | The [SAP outbound-delivery documentation](https://help.sap.com/docs/SAP%5FTRANSPORTATION%5FMANAGEMENT/14e2fd56dd2e43b1b9db5120dcd89bae/ae02b4e3b9ac11de2b8d000f20fcb6a9.html?ref=abundance.alloconomy.com), [purchasing confirmations](https://help.sap.com/docs/SAP%5FS4HANA%5FON-PREMISE/af9ef57f504840d2b81be8667206d485/1780b65334e6b54ce10000000a174cb4.html?ref=abundance.alloconomy.com) and [goods-receipt process](https://help.sap.com/docs/SAP%5FS4HANA%5FON-PREMISE/e3dc5400c1cc41d1bc0ae0e7fd9aa5a2/dad1db96c11b4368b24f4490a94ca151.html?version=latest&ref=abundance.alloconomy.com) give concrete examples of these internal records. They are examples of an implementation, not a required software design for every business. ### Billing and payment: a second branch | Step | Digital record created or updated | What I should recognize | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Billing** | Seller creates an **invoice**. | The payment claim. Depending on the arrangement, billing can reference an order, a delivery or part of either. | | **Invoice capture** | Buyer records a **vendor invoice** or **supplier invoice** in **accounts payable (AP)**. | The buyer’s record of the seller’s claim, with its own processing status. | | **Invoice matching and approval** | Buyer checks the invoice against the **PO**, **goods receipt** and any required acceptance evidence; updates matching results, holds and approval status. | Three-way matching names the PO–receipt–invoice comparison. It is a step, not another shipment or a payment. | | **Payment execution and reconciliation** | Authorized systems create a **payment** record, track processing and apply it to invoices. | An instruction, a completed payment and the clearing of a payable are distinguishable states. | | **Payment notification** | Buyer sends a **remittance advice** when used. | Which invoices and amounts the payment concerns. The advice is not independent proof that funds arrived. | Compare [SAP’s invoice references](https://help.sap.com/docs/SAP%5FS4HANA%5FCLOUD/a376cd9ea00d476b96f18dea1247e6a5/0e70b6535fe6b74ce10000000a174cb4.html?ref=abundance.alloconomy.com), [Microsoft’s vendor-invoice matching example](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/tasks/record-vendor-invoice-match-against-received-quantity?ref=abundance.alloconomy.com) and [accounts-payable process](https://learn.microsoft.com/en-us/dynamics365/guidance/business-processes/source-to-pay-manage-accounts-payable-overview?ref=abundance.alloconomy.com). **The invoice does not have to wait for putaway.** Its position in this picture does not impose a payment timetable. In our example, 100 books on the PO, 60 on the ASN and 58 on the receipt can all be accurate. The useful question is which lines and quantities each record references, and how the disagreement is resolved. ### The fields and neighboring records I also need **Buyer pays freight** and **seller pays freight** are plain descriptions of agreed freight-payment responsibility. They belong in the terms, alongside a separately identified transport arranger. They are not new transaction entities. Ownership, risk and the amount owed for the goods require their own agreement and evidence. The [inbound steps-and-records graph](https://abundance.alloconomy.com/alloconomy/before-the-shelf/#buyer-seller-construct-map) expands the physical branch: **freight unit → freight order**, **handling unit → ASN**, and **inbound delivery → goods receipt → warehouse task**. It also shows **dock appointment**, **inspection lot** and **usage decision**. The [customer-fulfillment graph](https://abundance.alloconomy.com/alloconomy/from-click-to-doorstep/#customer-fulfillment-construct-map) follows the next sale, from the consumer’s order to delivery and possible return. Before this PO there may be a **purchase requisition (PR)**, an internal request that can lead to a PO after approval; [Microsoft documents the distinction](https://learn.microsoft.com/en-us/dynamics365/supply-chain/procurement/purchase-requisitions-overview?ref=abundance.alloconomy.com). **Request for quotation (RFQ)**, **quotation**, **contract**, **credit note** and order changes are useful next terms when sourcing, adjustments or exceptions become relevant. Product, supplier/customer and location master records supply shared identity rather than being recreated with every order. For the longer explanation, follow [work before the PO](https://abundance.alloconomy.com/alloconomy/commerce-before-the-purchase-order/), [order and receipt evidence](https://abundance.alloconomy.com/alloconomy/commerce-sent-received-accepted/) or [invoice matching and disputes](https://abundance.alloconomy.com/alloconomy/commerce-the-140-dollar-disagreement/). The aim is a compact working vocabulary, not a measured claim that these records cover a particular percentage of every industry. *Sources checked October 22, 2026\. This directed acyclic graph follows selected records and handoffs forward. Real operations include changes, reversals and repeated work; those are outside this introductory view.* ## Continue the series Next: [Maya Sells to eComm Inc. Maya Also Sells Through eComm Inc.](https://abundance.alloconomy.com/alloconomy/commerce-who-is-selling-to-whom/). *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.*