I Bought a Book. What Had to Be Promised First?

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.

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 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 is the inbound inventory supply-chain series: preparation, transport, appointments, receiving and usable stock. 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; OASIS UBL defines the corresponding business documents. 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.

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, purchasing confirmations and goods-receipt process 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, Microsoft’s vendor-invoice matching example and accounts-payable process. 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 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 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. 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, order and receipt evidence or invoice matching and disputes. 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..

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.