Knowledge · Guide 6 of 8

A shared domain model for procurement

The same question must not get two different answers just because it was phrased differently. For that to work, procurement needs a binding description of what its terms mean and how its documents relate to each other. We call this a shared domain model.

When terms become ambiguous

Ask three colleagues in procurement what an open purchase order is. One means the goods have not fully arrived. The second means the invoice is still missing. The third means the process is not yet closed.

All three are right, but they mean different things. Between people, that gets sorted out in conversation. An AI takes the question literally and picks one meaning without saying which.

An everyday example

A purchase order is for 100 units and 80 have been delivered. The obvious answer to what is still missing would be 20 units.

In SAP, however, that line may have been closed as delivery completed. Then nobody expects another delivery, even though there is a numerical difference. The correct answer is that 20 units fewer were delivered than ordered, but the line is closed and no further delivery is coming.

This small example contains three different concepts, namely the quantity variance, the open delivery quantity and the expected further delivery. A domain model keeps them apart.

What a domain model defines

A domain model first describes the business objects of procurement, such as supplier, contract, purchase requisition, purchase order, goods receipt and invoice. It defines how those objects relate, for instance that an invoice line can refer to a purchase order line.

It then adds the meaning of states. What counts as open, closed, overdue or deviating? And finally context, meaning which document, organizational unit and point in time a statement applies to.

What the model does not do

A domain model does not replace the logic in SAP. Quantities, statuses and postings still come from the system. The model makes clear which of that data applies to which question.

Nor is it designed for all of procurement in one go. It grows along the capabilities that are actually needed. Where SAP already knows the relationships, the model adopts them rather than putting a second interpretation alongside.

What you gain

Answers stay consistent, because every capability uses the same terms. Follow-up questions work, because the AI knows which documents belong together. Ask about an invoice discrepancy and then which goods receipts belong to it, and you get a coherent answer rather than a guess.

The knowledge also becomes reusable. What a purchase order line means does not have to be reinvented for every customer. Only each company's specifics need adapting.

The next guide shows how the model proves itself on one of the most important checks in procurement.

Frequently asked questions

What is a domain model in procurement?

A binding description of the business objects, how they relate and what their states mean. It ensures that every answer uses the same terms.

Is this the same as an ontology?

An ontology is a formal, machine-readable form of such a model. We start with a lean domain model and formalize it wherever that demonstrably adds value.

Does the domain model replace the logic in SAP?

No. The data and its calculation come from SAP. The model defines which data applies to which question.

Want to see what this looks like in your procurement? Request a demo