A projector can illuminate a workshop. It cannot explain why a spreadsheet says both “paid” and “EUR 500 outstanding.” For that, the records need clearer jobs.

Lantern is preparing a community Repair Day. PO-104 orders one portable projector plus a setup service. INV-104 requests EUR 1200. OBL-104 records an original obligation of EUR 1200; after PAY-104's EUR 700 is allocated, its outstanding amount is EUR 500. These are connected facts, with separate identities and different questions to answer.

All people, organizations, records and amounts in this example are invented. The arithmetic assumes one currency and no tax, fees, foreign exchange, credits, reversals or other adjustments.

Start with what was requested

The order PO-104 records Lantern's request. CONTRACT-104 identifies the contract used as agreement context. The order and contract remain separate records: referring to an agreement does not turn a purchase request into the agreement itself.

The product describes the portable projector model offered or ordered. The setup service describes work to perform. One is a description of supplied goods; the other concerns provision of work. Neither is automatically the physical projector eventually sitting on the table.

ASSET-P17 identifies that particular unit. A product description can apply to many units, while an asset history follows one unit through delivery, use and maintenance. Attaching a unit's later lamp-hours reading to the product description would accidentally describe every projector of that model.

Vocabulary boundaries deserve care. Schema.org Product uses a broad definition encompassing offered products and services. This demonstration distinguishes product and service explicitly. Matching familiar names across vocabularies does not establish identical meanings.

Give the records practical properties

These conceptual properties make the example readable. They are not a complete API payload or a promise that semantic definitions enforce required fields, scalar types or cardinalities. Applications still need validation and business rules.

  • PO-104: Lantern's order for one portable projector and a setup service, with CONTRACT-104 as agreement context.
  • CONTRACT-104: contract reference and parties; relevant agreement document retained independently of the invoice.
  • INV-104: billed party Lantern, associated order PO-104, requested amount 1200 and currency EUR.
  • OBL-104: debtor Lantern, original amount EUR 1200, outstanding amount EUR 500 at this snapshot, and associated invoice INV-104.
  • PAY-104: payment amount EUR 700, payment date and financial account ACCOUNT-OPS; allocation recorded explicitly in the example's ledger context.
  • SHIP-104: shipment reference, associated order PO-104, supplied asset ASSET-P17 and destination PLACE-HALL.

ACCOUNT-OPS supplies account context for the payment. It is not Lantern itself, the person approving the purchase, or the mailbox receiving the invoice. A change to the operations email address should not silently rewrite a historical payment's meaning.

Original amount and outstanding amount coexist

OBL-104 is not a newly invented EUR 500 obligation replacing an earlier record. Its original amount is EUR 1200, and its outstanding amount in this simplified snapshot is EUR 500. Preserve both facts so readers can distinguish the starting amount from what remains.

The arithmetic is EUR 1200 minus EUR 700 equals EUR 500. That works because PAY-104 is explicitly allocated to this obligation and other adjustments are excluded. A EUR 700 payment somewhere in a bank feed would not, by itself, establish that this particular obligation was reduced.

The invoice INV-104 still requests EUR 1200. Replacing its amount with 500 would erase the difference between billing and outstanding balance. A later reviewer should be able to explain the change without guessing which meaning the amount column had when someone edited it.

The payment obligation also has a basis beyond an arrow in a picture. This story associates it with the invoice and agreement context; it does not claim an invoice necessarily creates an obligation. Diagram labels should say what is actually established: associated billing, payment allocation and outstanding snapshot.

One small example is not a universal workflow

This purchase deliberately uses one order, invoice and payment. General systems can allocate one payment across several obligations, several payments to one obligation, and invoices across different portions of supply. Preserve allocations rather than promoting this simple case into a universal one-to-one rule.

That matters for reporting. Joining an invoice to several payment rows can duplicate its requested amount when summed. Decide whether the question concerns invoice totals, payment movements, allocated amounts or outstanding obligations before choosing a join and aggregation.

Delivery has its own evidence too. “Invoice emailed” does not establish that SHIP-104 arrived. A shipment update does not prove the setup service was performed. The commercial records can be related without one status answering every question.

Follow the purchase into the next scene

PLACE-HALL is the venue in the event demonstration. ASSET-P17 then becomes the subject of the maintenance demonstration. Shared identifiers make those connections readable: the event uses the projector, and a task reviews that physical unit's condition evidence.

Can an invoice be partly paid?

In this example EUR 700 is allocated and EUR 500 remains outstanding. Keep requested amount, original obligation, payment, allocation and outstanding snapshot recognizable so the phrase “partly paid” can be checked.

Does shipment establish ownership or payment?

This example makes neither inference. SHIP-104 describes supply movement. Ownership, payment, receipt and service completion need their own relationships and evidence. The projector can stay out of the accounting department.

Explore the connected records

Download all three connected example journeys, or inspect the versioned source and its validation checks. The JSON is an illustrative set of records, not an interchange standard or a complete application schema.