[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Modeling multiple possible invoice totals based onpayment means
The presentation of an invoice from the buyer's perspective is an event within the overall invoice reconciliation and payment process. That process presents several nightmares that have prevented end-to-end automation. In the short term, "keeping it simple" is essential for any hope of adoption. By keeping it simple, I do not particularly mean keep UBL simple, but rather keep the partner trading rules simple. Rococo pricing structures and, as exemplified in this thread, special process fees and discounts create a very difficult invoice reconciliation and payment processes. What I have suggested to various players on both the purchasing and market/sales side is to stay away from complexity, because the "gain" (if any, in terms of incentives or revenue) is usually lost in the complexities of administration. Stating the same thing more positively, what we need are "eBusiness-friendly" contracts and pricing plans. Probably few people on this list control commercial terms, but we do need to be more aggressive in telling the people that do that the technology, although malleable, is not infinitely malleable. In a b-to-B world, the nightmares usually have to do with data and rule disconnects between the seller's internal order-to-cash process and the buyer's purchase to pay process - e.g., in terms of product nomenclature, unit pricing, taxation etc. The seller's system is more likely to fail with respect to customer identity and terms (e.g., multiple ship-to's, contractual domain definitions that cannot logically be linked to customer ship-to's, customer-customized terms, etc.). The buyer faces a difficult data maintenance problem to manage data regarding hundreds of sellers' invoices, products and terms and conditions. With respect to Andrew's point that with respect to loan repayment "no invoices pass between a lender and borrower," there are analogs in the more traditional purchase to pay cycle as well. Indeed, the early advocates of Reengineering cited "invoiceless payment" as the best way to eliminate invoice reconciliation and payment administrative costs. Those gains are still pretty elusive. Eliminating invoices means that the customer has to become "smart" enough about the seller's business to be able to compute the remittance advice without access to the invoice, because of course none exists (Evaluated receipts, also known as two-way matching). The buyer also picks up some tax computation reporting obligations. The buyer also has convey more information in the remittance advice, but as noted in this thread, that document stretches only so far. With respect to "Evaluated Receipts" see the description below extracted from an Australian governmental site. http://www.agimo.gov.au/publications/2002/11/dbowg/trade "Invoiceless trading Several Commonwealth Government agencies are using 'invoiceless trading' ...also called Evaluated Receipt Settlement...the buyer pays the supplier once goods and/or services have been provided satisfactorily (or at an agreed period after receipt), without waiting to receive an invoice... Under the [Australian] Goods and Service Tax (GST) arrangements, suppliers are generally obliged to provide a tax invoice to the buyer...the Australian Taxation Office (ATO) has issued a number of rulings relating to Recipient Created Tax Invoices (RCTIs) which ... allow the buyer (the recipient) to create a tax invoice in specified circumstances..." Whatever the national or local jurisdiction, the interposition of taxes adds complexity. If one looks ahead to, say, UBL 5.0 or UBL 6.0, perhaps the "state of the norm" of technology and systems design doctrine will have progressed to the point that we can standardize the transfer not only of "data" (however much enhanced by XML tags), but to transfer executable objects along with data that can be grafted onto the buyer's purchase to pay system to automate the "reconciliation" and pay choice options. Whether "transfer" means embed executables and data in a document to be exchanged or point to it as some web service or SAAS artifacts is another question. Because business and data complexity have tended to proliferate options and new data requirements, adoption of technology has lagged. Therefore, very often buyers' purchase to pay and the sellers' sales order to cash cycles are still most often "joined" through human rekeying and, whether automated or manual, exhibit very low Sigma. Fulton Wilcox Colts Neck Solutions LLC -----Original Message----- From: Andrew Chilcott [mailto:andrew.chilcott@stpsolutions.com] On Behalf Of Andrew Chilcott Sent: Monday, January 08, 2007 2:28 PM To: 'G. Ken Holman'; 'UBL-Dev' Subject: RE: [ubl-dev] Modeling multiple possible invoice totals based on payment means Ken I have had a quick look at the Remittance Advice and cannot see where the payment difference, albeit an allowance or a charge, would be placed (possibly as a separate debit or credit line item). I think that this presumes that any payment difference would need to be described in a debit or credit note which would then be referenced in the remittance line item. This is absolutely correct in accounting terms so that there is always the exact amount(s) to match off to in accounts receivable. In practice, I believe that this is the messiest part of accounting as the payer does not always (if ever) send a corresponding debit/credit note to cover any difference in the payment amount. In PISCES where I was project manager on the Lenders Conveyancing workgroup we developed a CCTS remittance advice that had the concept of an Allowance or Charge that could be notified in the Remittance Advice (see www.pisces.co.uk then navigate to Workgroups/Current Workgroups/Lenders Conveyancing/RedemptionRemittanceAdvice). Although the work done at Pisces was originally based on UBL it handles use cases that were way outside the remit of UBL and has therefore taken a slightly different path. In our case, no invoices pass between a lender and borrower so we had to come up with method that alerted the conveyancer/lender to items added to or deducted from the principal loan redemption amount. Andrew -----Original Message----- From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] Sent: 07 January 2007 20:10 To: 'UBL-Dev' Subject: RE: [ubl-dev] Modeling multiple possible invoice totals based on payment means Thank you, Andrew, for your response. At 2007-01-07 20:03 +0000, Andrew Chilcott wrote: >The adjustment to the payment amount should be dealt with in a >Remittance Advice which should also be able to handle the different currency options. Yes, I can see that the payer can use the Remittance Advice to indicate which of the payment terms they choose to accept. >The recipient of the monies can therefore book the invoice amount in >the invoiced currency against what is outstanding on accounts >receivable and the difference between invoice value and payment amount >gets posted to a revenue/cost item. Right ... which is constantly a mess for us since we don't have any Canadian customers. We are already doing this in our books, and over the 10 years it has wavered back and forth from being beneficial to deleterious. But from the perspective of the payee informing the payer of the options from which the payer can choose, would you disagree with my choice of enumerating the different payment terms and acceptable amounts in the invoice as I suggested? >From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] >Sent: 06 January 2007 21:53 >To: UBL-Dev >Subject: RE: [ubl-dev] Modeling multiple possible invoice totals based >on payment means ... >Looking again after learning from your note, I just found >"PaymentTerms" in which is found associated amounts, etc. > >So, perhaps then the invoice has the one total CAD$1000 and three >different payment terms: the cheque (no charge), the EFT (charge), and >the Internet (charge + currency). Thanks again, Andrew! . . . . . . . . . Ken -- World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]