UblOntology/Invoice

Formalization Proposal    (B3X)

• AdamPease's proposal and additional information    (B3Y)
  • an Invoice should be a FinancialText as defined in MILO    (B3Z)
  • MId-Level Ontology (MILO) that extends SUMO, there is the concept of a FinancialText which ultimately is a subclass of the SUMO term Text    (B40)
  • see: SUMO 1.566 (link to local file)    (B41)
  • MILO (link to local file)    (B42)

Definitions    (B43)

Ontolog Definition    (B44)

Reference Definitions    (B46)

• UBL Definition    (B47)
  • "complete information of the invoice"    (B48)

• xCBL 3.0 description    (B49)
  • "The Invoice comprises the creation of an invoice that is sent from a seller to a buyer for payment for the goods or services detailed in the invoice supplied under conditions agreed between buyer and seller. An invoice may refer to goods, items or services related to one or more orders. An invoice may contain references to payment terms and transport information."    (B4A)

Related Concepts    (B4B)

(taken from UBL_Library_0p70_Invoice.xls)    (B4C)

• UblOntology/ID    (B4D)
• UblOntology/IssueDate    (B4E)
• UblOntology/TypeCode    (B4F)
• UblOntology/TaxPointDate    (B4G)
• UblOntology/InvoiceCurrencyCode    (B4H)
• UblOntology/TaxCurrencyCode    (B4I)
• UblOntology/PricingCurrencyCode    (B4J)
• UblOntology/LineItemCountQuantity    (B4K)
• UblOntology/ReferencedOrder    (B4L)
• UblOntology/ReferencedDespatchAdvice    (B4M)
• UblOntology/ReferencedReceiptAdvice    (B4N)
• UblOntology/BuyerParty    (B4O)
• UblOntology/SellerParty    (B4P)
• UblOntology/PaymentMeans    (B4Q)
• UblOntology/PaymentTerms    (B4R)
• UblOntology/AllowanceCharge    (B4S)
• UblOntology/TaxTotal    (B4T)
• UblOntology/LegalTotals    (B4U)
• UblOntology/InvoiceLine    (B4V)

Open Issues / Work-in-progress    (B4W)

Concept Definition    (B4X)

• MikeDaconta first proposal    (B4Y)
  • "An invoice is a document which is part of a financial transaction between two or more parties and is a response to an order."    (B4Z)
  • GregOlsen's enhancement proposal    (B50)
    • "An invoice is a document which is part of a financial transaction between two or more parties requiring either the payment of monies or the granting of a credit and is a response to an order."    (B51)
      • Mike's comment: "I like the refinement of the definition. The distinction is important."    (B52)

• DuaneNickull's proposal    (B53)
  • "An invoice is a container data element that includes other data elements to convey a request for payment. The nature and number of the secondary data elements depends on the context in which it is being used"    (B54)
  • Duane's further comment    (B55)
    • The notion of "document" is from the paper world and IMO - deprecated for electronic business. Why should it be necessary to send everything all at once, packaged into a "document"?    (B56)
    • let's think outside the box (or document).    (B57)
      • 1. An invoice is a request for payment.    (B58)
      • 2. An invoice contains a set of information, the minimum of which can be determined by adding together each parties legal, administrative, technical, geo-political and other requirements and finding a common superset.    (B59)
      • 3. An invoice payment request can be made in more than one single transaction (go away from document).    (B5A)
      • 4. The order in which an invoice is received within a specific transaction will vary greatly depending on the nature of that transaction.    (B5B)
      • 5. An invoice can be "implied" ( A quote with a prepayment demand serialized inline??)    (B5C)

• MonicaMartin's comment    (B5D)
  • "what about the fact that an invoice resolves around payment for goods or services received. Then, taking that (and to Mike's and Duance's points), we have a transfer of resources (goods/services in exchange for payment). In the EAN.UCC drafts I've seen they have the notion of a commitment document (not a PO or a contract). Could this be related?"    (B5E)

• BobHaugen's followup to MonicaMartin's comment:    (B5F)
  • The EAN.UCC Commitment is based on the REA ontology.    (B5G)
  • An OrderLineItem typically represents two commitments, one to deliver some goods or services, another to pay for them.    (B5H)
  • When one of the commitments is fulfilled, a claim arises for the fulfillment of the reciprocal commitment. An invoice is a representation of a claim for payment.    (B5I)
  • But the invoice is not necessary, as DuaneNickull suggests above. The claim exists regardless of whether the claimant sends a document. In highly efficient supply chains, invoices are often regarded as waste and replaced by other practices such as PayOnDelivery, PayOnProduction, EvaluatedReceiptsSettlement, or SelfInvoicing.    (B5J)

• From the Random House dictionary [added by Patrick Cassidy]    (B5K)

   Invoice (1) "an itemized bill for goods sold or services provided, containing individual 
   prices, the total charge, and the terms."    (B5L)

   This suggests that the goods or services were already provided.  Is this
    invariably true for the charges in an "Invoice"?    (B5M)

• BobHaugen's followup to Patrick Cassidy's question:    (B5N)
  • If an invoice is a response to an order, what if the order is not fulfilled? Is the invoice still appropriate?    (B5O)
  • If the order calls for 100 items and only 50 are delivered, should the invoice be for 100 or 50?    (B5P)
  • A claim may also be made for the failure to fulfill a commitment, for example a penalty for late delivery or late payment. Such penalties may be added to invoices. What is the ontological basis for such claims?    (B5Q)

Naming conventions    (B5R)

• Names to use for identification of concepts    (B5S)
  • Default UBL Name ("ID")    (B5T)
  • BIE Dictionary Entry ("Invoice.Identification")    (B5U)
  • UBL XML Qualified Names ("urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70:ID")    (B5V)
  • "Invoice number"    (B5W)
  • Others    (B5X)

• Multiple languages    (B5Y)
  • "Facture" French    (B5Z)
  • "Rechnung" German    (B60)
  • "发票" Chinese    (B61)
  • Other language-specific representations    (B62)

Specifications    (B63)