Your EDI Resource

Three Main Reasons Why ePayments are Not eVerywhere

Posted by Shandra Locken on Fri, Feb 07, 2014 @ 11:06 AM

lockbox 360Photo appears courtesy of Naval History & Heritage Command.  Guest blogging today for the Aurora EDI Alliance is Carlos Rodriguez of DadeSystems. This blog is part three in a three part series on a virtual payment processing solution we are now offering called Lockbox 360. 

In my previous two blogs, I began a thread that we will conclude with this third installment. In these previous blogs, I discussed why checks still matter today and why businesses still prefer to use them. To wrap up these thoughts with you, we will now explore the three main reasons why ePayments are NOT found everywhere (yes, it IS a wonder).

As a banker, let me tell you why.

Reason 1) Checks are a Standard - eChecks are Not

As I stated in my last blog, “The check is a marvelous instrument, despite its humble and now-obsolete form factor,” and gave you the reasons why. We still have an entire generation of leaders left that grew up on checks, understand them and have not decided to eliminate this payment choice, “just in case.”  Since many, many businesses remain in the control of this generation of leaders, the check will remain as long as they do.

Also, I consider checks the closest cousin to cash. Sharing paper as a form factor, one has a fixed face value and one has a face value you control. This dual ability suffices for most human economic activities; it is as fundamental and basic as that. When an ePayment can do this easily, by anybody at any time, then a true new form of payment will be born.

And, unlike ePayments, checks ARE a standard. Also very basic and fundamental, but incredibly important. The check itself is the standard. Every bank in the world is able to process a check, for its face value. MICR, the standard font used at the bottom of the check, is not even really needed. In the banks, micr serves as a convenience, but in real time systems, “we kill the check at the teller line” anyway, so its 50 year old standard is nice to have and easy to use, but not necessary anymore. And, thanks to Mobile Capture, banks are waiving the need to present the physical item, defeating the micr line’s power as the first line of defense against fraud (because MICR ink contains actual ferrite particles in it, it denotes authenticity compared to a photocopied check).

As for the future, I definitely cannot stretch my vision too far there, but I can tell you the newest generation has never been exposed to a check, much less consider it as a payment option. I have now had the previously-unheard experience (now on several occasions) of having to describe a check, down to form and function to a younger individual, “’s about the size of your iPhone 5.” They absolutely had not seen one. You should see the look on their faces when I tell them they sign it, “...with a pen and everything.”

But, what really caught my attention is that, while they had “heard the term” check and had thought it had something to do with money, they had no concept of why or how you would use one. They are the first generation since the Medici to NOT know why checks matter. They do not know that there once was a piece a paper that stood in for cash, in any amount, but an expiration date (checks “state date” after six months). And, you mailed them?

Reason 2) No Standards

I do not wish you, the reader, to underestimate the absolute mess caused by the present lack of standards in payments. ACH payments are not checks, are not credit cards, are not wires,  and are not SWIFTS, which are not rdc (do not get me started on bitcoins). The current image standard for checks (ANSI x9.xx) is not anywhere near the EDI standard which has a subset health care definition, but not a check one. There is an ACH standard and EDI ACH standard (eBIDSACH from NACHA) but one is ubiquitous and one is an unpopular initiative (despite being excellent and actually, The Answer).

But, while it is easy to blame the standards (or a lack of adherence to them), I notice an obstacle even more fundamental to the problem - accounting systems themselves. As the final consumer of payment information in the payment process, you might think accounting systems are ALL about payments.  For those of us that deal with them, nothing is farther from the truth; accounting systems, with their self-absorbed point of view, give little support to interacting directly with payments. There is always an intermediate step, such as producing an “import” file and “exporting data” to report writers and other applications. Why can’t I pay an invoice from the invoice screen in my accounting system? Why can’t my accounting system ACCEPT a payment directly from another accounting system? Ever wondered that, Mr. or Mrs. Business Owner?

Instead, we end up with incredibly functional, fantastic standards that nobody uses. We also have a market chock full of amazingly-capable accounting systems, with all those incredible features. And yet, for the life of me, why is that no two are able to “talk to” one another, or even their bank, in any sort of direct, precise way? We actually need two-way fiscal “data exchange” between companies that could resolve such key pressing issues as discrepancies, discounts, clarifications, denials, approvals, eliminate float, accelerate postings and gosh-knows what other item your industry needs. All of these last items remain unsolved, ill-defined, widely-varying problems and issues across most industries.

Reason 3) Competitive Economics

“There is no incentive for me to use your standard. I like my preferred standard.” When investments and career decisions depend on your choice of providers and standards, it is difficult for the average decision maker to commit to one. What if they are wrong?

So, as we walk mentally thru that process, we empathize with the decision maker; it sure is difficult committing to a standard when even your best staff cannot promise you will “win.” In a horse race, I can pick winners and losers and I can blame myself for losses and congratulate myself for wins. But, in business, I do not have that luxury; if losses also mean you lose your job, your outlook will look decidedly be conservative and cautious. Committing to a standard that has the possibility of losing, even if it is a barely perceived hint of a risk, competitive economics dictate that I will select the outcome with the highest probability of success as one of its characteristics.

Now, let’s walk down the vendor’s point of view; we too empathize with the decision maker; it sure is difficult to ask the decision maker to use your carefully-designed standard. Since I as a vendor cannot guarantee my standard will emerge as the industry standard, I need to develop what will sell, so I can pay the bills. If what sells is a solution that does not need a standard, but uses existing paradigms, then I should have an easier time selling my solution. It should have a larger market. Few vendors push the envelope and I consider myself very fortunate to work at one such vendor. I see these differences and experiences above in my competitors, customers and prospects all the time.

And so, in conclusion, while checks have a foreseeable life span, the lack of a superior standard to replace them keeps them alive. While no standard exists for all payments, you should definitely push your vendors to strive for compatibility and extensibility. Set the standards. Force them to interact intelligently, in meaningful ways that matter to you. They are your vendors, they should satisfy you. Do not allow your vendor to pigeon hole you into their solution; do not let their competitive economics interfere with the smooth flow of yours!

Find vendors with open minds and even more open applications, willing to change their code for you. They exist, believe me.  And, having touched and tried some challenging projects before, you might be surprised at what they can deliver and what they can provide in the form of invaluable work experiences. They work with multiple customers, some even competitors of yours, so not underestimate a good vendor's ability to help you.

Click Now to Learn More  About Lockbox 360

Tags: data integration, Lockbox 360, Virtual Payment Processing, technology

EDI and Data Integration Resolutions for 2014

Posted by Shandra Locken on Fri, Jan 24, 2014 @ 11:08 AM

data integration

Photo appears courtesty of Luiza. It is a new year and as usual there are probably plenty of the things that you had to put off last year to due to budget constraints, time constraints or just plain old procrastination.  We thought we'd start off this year with a list of EDI and data integration projects to get accomplished in 2014.

1. Upgrade that Software -  Two big reasons why it's important to upgrade your software are support and evolving technology.  With respect to support, you don't want to be two versions behind, encounter a problem and find out that your version is no longer supported by your EDI vendor.  In order for a company to save a few dollars, they often will not take advantage of an upgrade and end up spending more later in support hours.  And upgrading more than one version is likely to cost more money and headaches than if you had just upgraded when the new versions were released.  Upgrades are meant to be done in a prescribed's almost always easier and more cost effective to follow that sequence.  

Technology evolves much faster than human life ever did.  Upgrading means you have access to the latest and greatest your vendor has to offer.  The world is opening up with the introduction of new formats like JSON and integration possibilities are more flexible than ever with the growing popularity of APIs.  In order to stay relevant and competitive, you must keep up with technological advances.  What happens when your 32 bit server crashes and your EDI software version is only compatible with 32 bit?  Now that 32 bit servers are obsolete, you must upgrade to 64 bit...the last EDI software upgrade supported 64 bit systems but you didn't upgrade.  You just made what could have been a minor mess, a much bigger one.  If you had only upgraded your EDI software when it was released, you could have just replaced your server with a 64 bit machine and your EDI software would support that change.  Now you have to not only replace your server, but you also have to upgrade your EDI software at the same time.  

2. Integrate your EDIIn an integrated environment, B2B transactions happen almost instantaneously, yet you can build in process controls for approval and/or exception handling for errors.  Integration helps uphold the integrity of your data since you are reducing the possibility of human error.  Data integration also helps keep your data secure.  Today’s data integration tools allow you to dictate who, when and how users can view and use data, which is especially important in industries like healthcare where the HIPAA police are watching.  Data management from a security standpoint gets more difficult as you add variables.  Lorraine Lawson of writes in her blog, “At one time, identities were easily segregated into ‘employee,’ ‘vendor,’ ‘partner’ and ‘customer.’  Which data you accessed, which applications you used were based on these hard identities, but no more as companies see the value in exposing some of the same information or applications to customers, employees and partners.”  As CEOs and business owners begin to see the value in tools like marketing automation, Webstores, PunchOuts, as well as EDI, integrating all these processes will be necessary to maintain data security.  

Ultimately, integration keeps you at the top of your game in the marketplace.  It's not uncommon today to find a small company selling artisan toffee to the big retailers using EDI, all while also selling direct to consumers using an e-commerce site AND successfully marketing using social media.  The difference between them and those on the cutting edge is that the latter has all of these processes integrated.  Kevin Jordan of Tibco writes in his blog, “With an integrated platform, it becomes possible to predict what a customer or client will do with accuracy, and allow for a decision based on a customer’s historical data correlated with real-time events.  Imagine this: A customer is wandering around a store trying samples and suddenly receives an email or text offer for that product. Upon opening the message, it can also display some of the customer’s regular purchases and favorite products as an added offer. With well-integrated systems, the company has the opportunity to exceed shopping expectations.” 

3. Adding Additional Servers - Have you been thinking about adding additional servers for testing and development or live failover?  Now is the time.  If your business has grown to the point that you need a separate environment for testing and development then do not delay.  Budgets get committed early in the year.  Just a few reasons that come to mind for adding a dev/test environment include protecting your production environment from trading partner changes.  Also, having a test environment allows you to test updates before sending erroneous data to your trading partners - eliminating charge backs and damage to your relationships.  On the hardware side, you can safely make changes and/or updates over the weekend with peace of mind.  Lastly, additional environments limit your risk of catastrophic server failure which will affect your sales and delivery process, disrupting your entire supply chain.  If you are asking yourself whether or not you need separate environments for dev/test and production, then ask yourself how your business would be affected by having your systems down.  Microsoft suggests that in any enterprise software solution, "At a bare minimum, you should separate the production environment from the other environments."  In a perfect world, everyone in the organization would have their own sandbox to play in, software testers, developers, etc.  But if that's not possible, you must at least protect your production environment from human error and mechanical failure.

4. Miscellaneous Projects - This list could really go on and on.  Other projects you may be considering include getting back on a software maintenance plan, adding additional trading partners, embarking on a data cleansing project, updating your payment processing system, tightening up that disaster recovery plan, or looking at different ways to analyze your data.  Regardless of what projects you are considering, get them on the calendar and get them in the budget.  And let’s gitter' done!

Click below to see how we helped a medical supply company completely reconstruct and optimize their EDI and data integration solution.

Download AliMed Case Study

Tags: EDI integration, EDI Technology, EDI considerations, e-commerce, integration software, EDI software, data integration, supply chain, Lockbox 360, Virtual Payment Processing

Payment Processing: The Case for Wine Part 2

Posted by Shandra Locken on Fri, Dec 20, 2013 @ 12:48 PM

payment processingPhoto appears courtesy of Seattle Municipal Archives.  Guest blogging today for the Aurora EDI Alliance is Carlos Rodriguez of DadeSystems. This blog is part two in a three part series on a virtual payment processing solution we are now offering called Lockbox 360.

While still in the course of a long career processing all kinds of payments for all sorts of firms, every now and then a very rewarding project presents itself. Such was the case of a very well-known wine distributor and their payments. And, if I let slip any wine-related double-entendres during the course of the article, you will please forgive this humble writer, as they were purely unintentional slips of the palate.

Also, I want you, the reader, to remember the following saying; “For any activity, it takes 1,000 repetitions to make an expert”.

To paint this picture, we move to sunny California. There, a major bank’s staff busies itself with the work of opening a particular set of envelopes destined for our now-customer, arriving from all over the State to their processing facility in San Francisco. This set of envelopes contains payments arriving by various means; delivery trucks getting checks from small-to-medium size supermarkets, bodegas, restaurants, hotels and all manner of wine consumers, as well as stores, hotel chains, and corporations all stocking their wine coolers and cellars.  Just picture the variety (no pun intended), Beaujolais to Half-Moon Bay, Sauvignon Blancs to Sausalito, Syrahs to Santa Barbara, etc.

As usual, some of these customers pay using the original invoice stub containing a nice, carefully mapped listing of all the amounts due from the customer, called their receivables listing. But, MOST toss this nice, convenient and useful document and simply elect to submit a payment using their own remittance document (“I’m paying you for this and this invoice now only”), as printed by their accounting system. Again, and this is important, NOT any coupon or other document given to them, 15,000 plus of the every month, free of charge,  by my customer, to help facilitate matching the payment back to its original invoice. Gosh, no; that would be too sensible and convenient.

Some years back, the decision was made to “outsource” the payments to the bank. I worked in banks for decades and I understand the reasons. The customer would have to go to the bank anyway to make the deposit; this saves the trip. It is more important to deposit the funds than to perfectly account for every payment (I know, it sounds loony, but that is the math). For the bank’s part, they get to charge fees for processing the payments, they get to keep and use the customer’s compensating balances and the receivables lending opportunities (cross-sales) it affords the bank. The lender gets a loan (interest income) and the bank gets fees (non-interest income). Sounds ok, so far. Like many good ideas on paper, in practice, much can, and very frequently does, change.

So, now picture what our colleagues at this very major bank have to do to even offer their lockbox services; regardless of the type of document, regardless of the condition of this document, whether or not the payment even belongs to our customer, they have no choice but to blindly process that payment as best they canInevitably, and predictably, a large number of these payments, despite their best efforts, simply cannot be processed, for one reason or another. In the industry, we call these “exceptions.”

Rather than mis-post, or posting incorrectly altogether an exception, the bank simply “FedEx’s” the payments to the customer, sometimes posting them to a clearing account, sometimes sending them back to the customer outright. In both cases, an unnecessary and costly delay in depositing the funds is artificially imposed by this inefficient and cumbersome approach to processing payments. It is that pig-headed, that primitive and that straightforward. It is one of the reasons I considered owning stock, not in the bank, but in Fedex. Almost every big bank is doing this and every big bank uses one of the majors to send their lockbox exceptions back.

This is ok when you have the occasional exception. It is alright when you just want to be careful posting this one million dollar payment (some of the checks are that big). What is NOT ok is to receive 10-15 thousand payments and send 40% of them back to your customer as exceptions. YOU have to pay them 100% of a contract, to do 40% of the work yourself? I have thought about it a lot and, yup, that is what it means, in practice, where it counts. Pretty crummy set of affairs.

But, wait, there’s more….

And, for the 60% of the items you do match, it is woefully inadequate to miskey a posting so badly it leads to an adjustment downstream (double the work, double the cost). The bank keys it wrong and the error is discovered at posting, so your staff spends their time correcting the bank’s mistake. Ouch.

And, there is still more. For the 60%, the woeful industry average of miskeying payments (keyed by experts), is one error leading to an adjustment every 275 keystrokes. One payment may contain 10 to 1,000 keystrokes or more. This number of 275 is the natural incidence of human error for this type of activity, a statistically-significant number painstakingly arrived at after keying untold billions of payments, year-after-year. Do the math; there will be a fraction of payments, every day, that will contain errors, under this bank’s older processing model. This and most other banks.

Think about it; our customer had to keep staff to handle the exceptions that the bank could not. Not much of a savings for all the money they paid monthly. Not to mention, our customer missed out on earnings on what worked out to be about $150,000 a month, which is not an insignificant amount of float risk. Some months, it worked out to an estimated loss of about $4,000 in funds availability per business day just in these un-deposited funds, day over day. Who says the decision to have somebody process your payments does not have consequences? Like any other discipline, there is more to processing payments than meets the eye.

Why does this happen? The dirty little secret of the industry is not that dirty at all; it is just HARD to match payments, especially somebody else’s payments. Nobody uses the coupon you give them; for efficiency reasons, it does make sense to pay all your vendors using your accounting system’s own ability to issue remittance list to accompany the payments you issue to them.

But, these payments are so different that there is a natural incidence of them that no processor is able to match, without “The Alpha”. The Alpha is short for “the alphabetic or indexed listing of all your customers”. It is nothing more than your list of receivables. So you know, the state of the industry is to NOT have this one available, as the perception has traditionally held that it would be too costly and too inefficient to try to obtain the receivables list from all your customers (after all, it is a list of all their customers). That is where we are different.

So, every single day, our colleagues at this big bank send out piles of Fedexs to their customer containing all items they could NOT match.

Imagine a system that does sport the rare ability to incorporate, on a daily, routine basis, the receivables file containing the aforementioned “alpha.” Now, we are able to see the work AND see the alpha, which is fully text-searchable. Best yet, by design, operators are only allowed to select from valid receivables entries (or create a new one, for some). By selecting from only valid entries, errors are reduced to an absolute minimum (not eliminated, but reduced to the limits of what is possible).

But, and here is my favorite part. This is the part of the story where the little company again outmaneuvers the larger predator (the big banks with their older methodologies), affording its customers a competitive advantage no predator provides today. At the end of each business day, when all the incoming payments have been matched to their respective receivables line items, a new posting file is produced containing a subset of the self-same data imported in the morning; not a new file, not a corrected file, but a mere fragment of the original file. When IT posts, it posts perfectly.

Let us think about why, and about why this is important. Normally, the bank keys each and every payment. There is no alpha to compare to, so they blindly key (and charge you a very pretty penny for the privilege) each and every incoming payment. Of course, if an item does not meet the contractual norm, you now pay for a Fedex of the item, the work you now have to key in using your staff, plus the inevitable delay in deposited funds (and availability to you). It seems primitive; oh, that’s right. I already said that.

Now, compare it with the new workflow now in use. Payments come in and proceed to match automatically. Then, once the computer has had a crack at the images (it goes first, as it does not sleep, get tired, distracted, does not get flats coming in to work or need to pick up the kids is accurate, reliable, and does not need much health care). A subset, most days a small subset, of the items is “workflowed” to operators (anywhere you like). Each payment combo is met with a list of most likely candidates (or the operator filters and searches in seconds); once its matching receivable record is found, it is selected. No keying. For those of us who have keyed for a living, we would MUCH rather be in charge of a system that learns to key than to key ourselves.

Recall when I asked you to remember that it takes 1,000 repetitions to make an expert? That is what those of us that keyed for a living are; experts, some of my colleagues and coworkers certainly are Grand Masters. Like any human activity, mastery takes practice and repetition. Look around your firm and think about which tasks that person, that colleague of yours, has repeated 1,000 times or much more. That person is an expert at that activity and that expertise is an asset.

Now, lets us think about the economic value, the incremental value of that activity and what it represents to your firm. Ask yourself this; “ Is there any value to my colleague performing the activity 1,001, 1,002 or more times?” The answer is the value to your firm declines with each repetition. That person should move on to a higher and better task, such as supervising new staffers or letting an automated system handle the taskAnd, for heaven’s sake, who better to run the automated system than your in-house, painstakingly trained expert(s)? After all, who knows the work better than your experts?

And, finally, I wish to address with you, one salient point about all this payment processing. Ask yourself what business are you in? Now, that you have the answer, is that business payment processing? For the few who answer yes, skip this.

For those of you that answered anything else, the realization is that, NO, you are NOT in the payment business. Therefore, you realize you cannot know what all your options are. You realize you are not able to capture the highest efficiencies those that ARE experts are able to capture. You realize you cannot hope to stay abreast of advances in efficiency like the ones described above. I work this field and it is as challenging as yours is to keep abreast of, I know you believe that. You need experts in the field to point the way and this is definitely one of those fields. You need to listen to honest advice and use your common sense. Does it make sense for me to worry if I am processing as efficiently as possible? What is the cost of NOT doing it as efficiently as I can? How can I worry about that when my business demands all my attention?

A simple calculation you probably make every day; what IS the opportunity cost of dealing with payments and NOT your business is; $100/hr? $1,000/hr? $10,000/hr? More? That should give you direction and answers on how to proceed, right?

It flat out did for the wine company and they are very happily processing every day, saving about $10,000/month in bank charges and have the best funds availability they ever enjoyed. It made common sense to them. I hope it does to you and do not settle for wasting your time. Instead, enjoy a good California wine. My happy wine customer and I both thank you for your future business.

Click below to schedule a demo on Lockbox 360, the new virtual payment processing system being offered by the Aurora EDI Alliance.

Click Now to Learn More  About Lockbox 360

Tags: Lockbox 360, Virtual Payment Processing, technology

Payment Processing: Why Checks Still Matter Part 1

Posted by Shandra Locken on Fri, Nov 22, 2013 @ 10:26 AM

lockbox 360Photo appears courtesy of wsssst. Guest blogging today for the Aurora EDI Alliance is Carlos Rodriguez of DadeSystems. This blog is part one in a three part series on a virtual payment processing solution we are now offering called Lockbox 360.

As an experienced banker and bank operations person, I have worked directly in the bowels of banks and the companies we served. We handled their deposits, often balancing their addition errors for them (which is why we do so much dual control), sorted and posted their payments, even creating posting files to automate the posting and to reduce errors). Hence, it is no surprise to me that the check continues as one of the most heavily used forms of payment between businesses, with their combined face values outstripping credit card and ACH totals by 5 to 1.

As a banker, let me tell you why.

The check is a marvelous instrument, despite its humble and now-obsolete form factor. Businesses like it for a long list of reasons, but the most important ones are; 1) it can be of any amount, 2) it is issued on demand, suiting the business, 3) with imaging, its cost compare to those of ACH payments, and 4) it “floats”, allowing for extra cash flow days every business needs.

The need and interest in float is universal across all businesses and the check trucks right along helping provide that. Remember, ACH, by definition, will not provide float to a business, as availability shrinks or is regulated away  (see Reg CC).

Regardless of the payment type you accept, all of these methods require an internal investment in time, effort and processes that usually have nothing to do with what you do. It makes sense to adopt efficient internal mechanisms that insulate your business from unnecessary costs related to the simple act of accepting a payment. For example, I work with a lockbox vendor that produces perfect posting files for our merchants or their customers extracted from and automatically compared to the incoming payments (the term “lockbox” in banking refers to internal or external business payment processing services provided inhouse or outsourced to a business account holder).

But, in banking and as experts in processing payments (which IS our real business), we specialize in automating one of the most labor-intensive aspects of accepting a payment. By providing these services, the bank’s business customer obtains real value from their bank relationship; a huge savings in key-entry time and a change from an error-prone to an error-free posting. No more hunting down out-of-balance conditions with your general ledger and no unmatched items in your receivables. The business now can count on its posted totals, increasing liquidity while reducing payment risk.

So, I strongly urge you to look at how your business accepts payments and do not look at the check as a bad payer. Remember, it lets you float a payment in the mail, it lets you write it for any amount on demand, it is accepted across all businesses as legal tender (something PayPal or even Square cannot claim).

Finally, in a cruel twist of irony, recent changes to the laws revolving around payments have created a very unusual situation. As CFO and accountants well know, due to increased fraud in electronic payments in general, recent changes to consumer finance legislation have extended the payment return date on credit card and ACH payments from 45 to 90 days. Anytime within that 90 day period, a customer can unilaterally return a payment claiming fraud or other protected claim under the reg. Checks, on the other hand, remain at 45 days, meaning the risk of return of payment is half that of credit card or ACH payments.

So, a very large commercial account told me that they now consider electronic payments twice as risky, for liquidity purposes, as the exact same payment made by check. This merchant now asks all its thousands of customers to pay them by check. They reduced their exposure to returns by going down this route, while cementing their liquidity calculations around the “safer” 45 day period afforded by checks.

Talk about your unintended consequences.  

Please click below for more information about virtual payment processing.

 Click Now to Learn More  About Lockbox 360


Tags: Lockbox 360, Virtual Payment Processing, technology