RE: [ubl-dev] Modeling multiple possible invoice totals based onpayment means

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

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