Use Case for Invoice Validation (BH8)
- General Description: The ability for a software agent to validate that an Invoice is accurate both internally and against an Order (if one is referenced). (BH9)
- Types of validation: <Please add stuff here!!!> (BHA)
[PatCassidy] One foreseeable problem is where the customer orders one item and the line item in the invoice is not an identical string -- though it is the same item. i.e. the customer and vendor call it by different names. Has this been discussed yet? I know that reconciling different vendor catalog names has been an issue in e-commerce, but don't know if anyone has claimed to resolve it yet. At VerticalNet we made a beginning by creating an ontology of articles of commerce, but that never reached a functional state before the ontology effort was disbanded. Just reconciling the number of items ordered versus the number shipped (or backordered) will be a first issue. Since reconciling different names is almost as difficult as language understanding, I think it may be necessary to require that order line items be numbered and that the invoice must reference the order line items, not just the order. (BHB)
[BobHaugen] The normal use case here (for companies that still do it) is 3-way Match: Invoice, Order and Receiver. The buyer does not want to pay for items that were not received in good condition. All matches go down to the detail items. (BHC)