OAGi — OAGIS and Business Object Documents

The de-facto canonical-model standard for ERP integration. OAGIS encodes business interactions as BODs combining a noun and a verb — ProcessPurchaseOrder, GetItem, SyncCustomerParty, ConfirmBOD.

What is OAGi and OAGIS?

OAGi is an open consortium founded in 1994 by North American ERP vendors and large end-users to solve the dominant problem of the era: point-to-point integration between heterogeneous systems (SAP, Oracle, JD Edwards, PeopleSoft, Baan…). Rather than writing one mapper per application pair, the idea was to publish a shared vocabulary: a normalised set of business objects and verbs so that every ERP could produce and consume canonical messages.

OAGi's flagship product is OAGIS — Open Applications Group Integration Specification. OAGIS defines two foundational building blocks: a library of nouns (business objects such as PurchaseOrder, Invoice, Item, CustomerParty, Shipment) and a set of verbs (canonical actions such as Process, Acknowledge, Confirm, Get, Show, Sync, Notify). Coupling a verb with a noun yields a BOD — Business Object Document, the fundamental exchange unit.

BOD architecture

Every OAGIS BOD follows the same binary structure: a technical envelope (the ApplicationArea) and a business payload (the DataArea).

This decoupling lets the same Item be manipulated by any action: GetItem (read), ShowItem (response), SyncItem (master data push), ProcessItem (transactional action), AcknowledgeItem (acknowledgment). The explicit verb + noun coupling is the singular trait of OAGIS compared to more monolithic standards.

Anatomy of a ProcessPurchaseOrder

The ProcessPurchaseOrder BOD is the canonical equivalent of an EDI 850 or an ORDERS: a buyer issues a purchase order to a supplier. A condensed example in OAGIS 10:

<?xml version="1.0" encoding="UTF-8"?>
<ProcessPurchaseOrder
    xmlns="http://www.openapplications.org/oagis/10"
    releaseID="10.11" versionID="10.11">

  <ApplicationArea>
    <Sender>
      <LogicalID>ERP-CENTRAL-EU</LogicalID>
      <ComponentID>PurchasingModule</ComponentID>
      <ConfirmationCode>OnError</ConfirmationCode>
    </Sender>
    <CreationDateTime>2026-05-14T10:15:00Z</CreationDateTime>
    <BODID>5a8f7d2e-2b15-4c1a-9e6f-acme-2026-0014</BODID>
  </ApplicationArea>

  <DataArea>
    <Process>
      <ActionCriteria>
        <ActionExpression actionCode="Add"/>
      </ActionCriteria>
    </Process>
    <PurchaseOrder>
      <PurchaseOrderHeader>
        <DocumentID><ID>PO-2026-000871</ID></DocumentID>
        <DocumentDateTime>2026-05-14T10:00:00Z</DocumentDateTime>
        <BuyerParty>
          <PartyIDs><ID>4012345678901</ID></PartyIDs>
          <Name>Acme Industries</Name>
        </BuyerParty>
        <SupplierParty>
          <PartyIDs><ID>5790000123456</ID></PartyIDs>
          <Name>Northern Components</Name>
        </SupplierParty>
        <RequestedDeliveryDateTime>2026-06-04T08:00:00Z</RequestedDeliveryDateTime>
      </PurchaseOrderHeader>
      <PurchaseOrderLine>
        <LineNumber>1</LineNumber>
        <Item>
          <ItemIDs><ID>RBC-2200</ID></ItemIDs>
          <Description>22 mm ball bearing</Description>
        </Item>
        <Quantity unitCode="EA">240</Quantity>
        <UnitPrice><Amount currencyID="EUR">8.40</Amount></UnitPrice>
      </PurchaseOrderLine>
    </PurchaseOrder>
  </DataArea>
</ProcessPurchaseOrder>

The generic structure is visible at a glance: the ApplicationArea identifies the sender (LogicalID, ComponentID) and stamps the BOD with a UUID (BODID). The DataArea opens with the verb Process and its ActionExpression (Add — create), then the noun PurchaseOrder with its header (PurchaseOrderHeader) and lines (PurchaseOrderLine).

The OAGIS verbs

OAGIS defines about ten primary verbs. Each one captures a precise business intent, and every canonical BOD is the combination of a verb and a noun.

Most-used BODs

The canonical BODs most frequently encountered in real ERP integration architectures:

Documented BOD catalogue

Detailed pages available on ediverse for 50 canonical BODs, grouped by functional domain (procurement, logistics, catalogue, master data, sales, finance, manufacturing, HR):

Procurement

Logistics

Catalogue

Item master data

Party master data

Sales and quote

Finance and accounting

Production and manufacturing

Warehouse (advanced logistics)

Human resources

OAGIS 9, 10 and beyond

OAGIS has evolved through successive generations.

• OAGIS 8 (2002-2007) — first stable XML format, strongly SOAP-oriented, still present in some legacy platforms.
• OAGIS 9 (2008-2014) — modularity overhaul, reusable Components added, clearer ApplicationArea / DataArea split. Very widespread across US aerospace and automotive in the 2010s.
• OAGIS 10 (since 2014, incremental releases 10.0 → 10.11+) — current foundation: further modularisation, canonical JSON serialisation alongside XSD, native REST integration, and the Score platform replacing the historical code generation tool.
• connectSpec — newer envelope being standardised inside OAGi: same BOD grammar as OAGIS 10, but REST-first formats and tooling. Versions 10.12 / 10.12.1 have been published on oagi.org.

Use case: canonical ERP model

The flagship use case for OAGIS is the canonical integration model (canonical data model). In an architecture where multiple ERPs, MES, WMS and PIMs need to interconnect, rather than writing N × (N − 1) bilateral mappers, you define a single canonical format in the middle — OAGIS — and every system publishes and consumes through that pivot. The number of mappers drops to N, and each new system added to the ecosystem only costs one extra mapping.

OAGIS thus sits opposite traditional EDI (EDIFACT, X12), which is still focused on inter-company B2B exchange. OAGIS operates mostly inside an extended enterprise or an industrial group. Many integrators orchestrate both side by side: EDIFACT / X12 at the edge, OAGIS inside.

Further reading

• oagi.org — official website, free download of OAGIS 10.x specifications and connectSpec.
• Wikipedia — OAGIS (the page may 404 depending on renames — fall back to the OAGi category).
• EDIFACT on ediverse — compare equivalences ORDERS / ProcessPurchaseOrder, INVOIC / ProcessInvoice.
• UBL / PEPPOL on ediverse — another XML BOD family, centred on European public e-invoicing.