At 08:31 AM 10/2/01, David Goldberg wrote: >-Integration with existing A/P and A/R systems: The sheer number of various >ERP systems currently installed within enterprises, and the systems-related >investment constraints of mid-sized and small businesses, seem to leave only >paper checks as the only ubiquitous payment solution. However, given the >remittance, security/fraud and settlement timing issues associated with >checks, buyers and sellers need an electronic payment solution that is >acceptable and usable by companies of all sizes. Therefore, the ability of >any payment and settlement application to integrate into these systems and >software, without necessitating changes to those systems, makes remittance >flow and reconciliation even more efficient.
These posts are very informative. I hope that one or more readers of this thread, will contact the ArapXML consortium and contribute to the OMG ARAP submission now underway there. http://www.arapxml.net/ The OMG RFP for AR/AP is for global reconciliation and settlement of interparty balances. http://www.omg.org/techprocess/meetings/schedule/AR_AP_Facility_RFP.html You can't automate business processes starting at the payment and settlement. Example: digital cash failed, on inconvenience and lack of business integration. You have to start earlier in the business process. AR/AP is founded on the GL which is the earliest stage of event recognition that is ubiquitous enough to allow global reconciliation. Cover review last week http://xml.coverpages.org/ni2001-09-24-b.html Hope this helps, TOdd Todd Boyle CPA 9745-128th Ave NE Kirkland WA [EMAIL PROTECTED] 425-827-3107 Oslo [47] 9822-7366 my employer www.netaccount.com our project www.arapxml.net website www.gldialtone.com >David, >It seems that there is indeed a lot to do in the area of payments! >Keeping payments information-rich seems like a good idea. > >One way is that operations are accumulated (typically using XML) >so that > >- an order is signed by the buyer and sent to the seller >- the order is put in an invoice container signed by the seller and sent >to the buyer >- the invoice in put in a payment request container signed by the buyer >and sent to the bank >- the payment request is put in a payment response container signed by the >bank and sent to the buyer who sends it to the seller > >An entire business process in *one* document. > >Nor for the faint-hearted byte-savers but surely workable. > >Anders > >----- Original Message ----- >From: "David Goldberg" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Tuesday, October 02, 2001 16:36 >Subject: FW: The end of P-Cards? > > >Anders: > >There is one basic issue that has not been addressed in any of the emails in >this string: cost! > >I agree with the P-card strengths outlined in some of the other emails, e.g. >added level of control, fast settlement for the seller, ubiquity, etc. I >believe P-cards are a relatively efficient mechanism for settling both >e-commerce and traditional commerce....with one caveat. That is, as long as >the value of the purchase stays below, say, $1,200. P-cards charge the user >a percentage of the purchase value as a fee. For smaller corporate purchases >they make some sense. Above this level the economics break down very >quickly. This limits the overall usage and ultimately the value of P-cards >as a business-to-business settlement mechanism. > >This is one of reasons why corporate America continues to write over 25 >billion paper checks each year to settle B-to-B commerce (this and other >issues relating, for example, to the adoption issues around fEDI and other >electronic settlement options--but that's another story.) > >What commerce needs is a settlement mechanism that supports B-to-B >settlement with: > >-Quick and efficient settlement: Banks, the subject of another email in this >string, maintain an effective inter-bank clearing network, i.e. ACH and >other country-specific networks, that is actually very efficient at moving >money between bank accounts at different banks. Until there is a better >solution, banks will continue to play a valuable intermediary role in the >world's ability to move money. Commercial settlement solutions should >leverage this strength. The real issue here is that the ACH network, albeit >effective at moving dollars, is ineffective at moving the data associated >with those dollars (see next point). > >-Rich remittance information: One of the least efficient and costliest >activities involved in B-to-B settlement is the time and resources it takes >to generate payments on the buyer side and, even more so, post and reconcile >payments on the seller side. Buyers and sellers both benefit significantly >when remittance information and addenda records move with the payments >through the system. The largest value-add for either participant would be >the ability to include as much descriptive remittance as is required for >more efficient back-office payment processing. Furthermore, the need to keep >the "dollars and data" together from end-to-end is critical. Once separated, >as happens with a fEDI transaction that flows into a bank for back-end ACH >settlement, remittance information requires manual processing or re-keying. >When bits turn into atoms and back again, errors inevitably occur. All you >have to do is ask your nearest Account Receivable Manager or Controller >about the remittance and reconciliation limits of ACH, fEDI, P-Cards and >paper checks. > >-Integration with existing A/P and A/R systems: The sheer number of various >ERP systems currently installed within enterprises, and the systems-related >investment constraints of mid-sized and small businesses, seem to leave only >paper checks as the only ubiquitous payment solution. However, given the >remittance, security/fraud and settlement timing issues associated with >checks, buyers and sellers need an electronic payment solution that is >acceptable and usable by companies of all sizes. Therefore, the ability of >any payment and settlement application to integrate into these systems and >software, without necessitating changes to those systems, makes remittance >flow and reconciliation even more efficient. A buyer should be able to >generate their regular pay run within their existing A/P system environment >and process, include addenda in the proscribed format of that system and >disburse it electronically to all of its vendors regardless of vendor size, >systems capabilities or preferred remittance format. Likewise, a seller >should be able to receive remittance in their A/R system's proscribed format >for electronic uploading and posting, from any of its business customers >regardless of size, systems capabilities, etc. > >-Security: Digital signatures using strong PKI encryption, buyer- and >seller-side system access controls and secure Internet transmission are all >available technologies to solve the critical authentication, theft and fraud >protection issues. These should be table-stakes in today's commercial >environment. > >-Standard pricing for transactions of any value: Again, P-Cards are a >reasonable solution for low value purchases. However, a payment solution >that doesn't price discriminate between a $100 purchase of office supplies >or a $100,000 purchase of a backhoe seems to be the better answer. > >Will a solution such as this ultimately replace the payment and settlement >mechanisms relied on today by the commercial world? Perhaps. Change will >occur slowly at first. Will there be a time when tradition settlement >mechanisms and the artifacts that enable them, e.g. P-cards, are a thing of >the past? I believe so. > >David A. Goldberg >[EMAIL PROTECTED] >Clareon Corporation > > > >-----Original Message----- >From: Anders Rundgren [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, October 02, 2001 1:45 AM >To: Geoff Browne; [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: Re: The end of P-Cards? > > >Geoff, > > >Seems to me that everyone's missing the point..... > >Not really, just a definition kind of problem. > > >The value of a PCard is two-fold: > >* it enables the Buyer to establish controls over who buys what for how >much > >from whom (and reducing maverick spend is a key benefit of eprocurement for > >both buyer and supplier) > >I Agree > > >* it ensures the Supplier receives guaranteed payment (less PCard fee) > >within 2 - 4 days of purchase, compared with 60 - 120 days in mainstream > >circumstances. > >I Agree > > >With eprocurement systems capable of being configured with a virtual Pcard > >number according to user setup configuration (and I agree that there needs > >to be tight security around this), limits are placed on misuse / maverick > >spend. > >This is exactly what my original posting was about. If it is a virtual >Pcard >or a 3D Secure virtual Visa card seem irrelevant assuming that it is >the eprocurement system that do the checking (rather than the seller >doing a register lookup). > >Anders
