Rohit Patel Webinar: Amazon Vendor Returns Processing

SPEAKER: Rohit Patel, Credit & Collections Expert and Consultant

We're going to go through new/old A/R problems with returns, the potential solutions that are available, and the top benefits of robots for returns automation.

Returns have been a problem for a long time, ever since suppliers first sent products to retailers, but it has a new twist. Returns are complicated, and customers request returns for multiple reasons. It can be because they no longer want the product, the product is defective, or retailers purchased too much product and they don’t want it sitting in their inventory. A lot of people call that restocking, so they want to return that product. A damaged product box is another reason, which could be the supplier’s, shipper’s, or receiver’s fault.

There is also the complication of 'wrong product,' where a competitor's product as well as your own is received. This makes the reverse-supply chain very complicated and creates a lot of nuances, especially in the deductions area.

Here is one example of potential complications: a consumer orders something from Amazon and wants to return it. They go onto the portal, and request that product to be returned. Sometimes Amazon will give the customer a credit immediately, and they may not even want the product back. Knowing Amazon is going to credit the individual, we also they're going to chargeback the supplier and take that deduction immediately from them, even before that return has been received. Amazon will often allow 45 days for a product to be shipped back. If the item doesn't get returned, Amazon should automatically reimburse the supplier. However, that doesn't always happen. A wise supplier should always keep track of and validate all of the debits and credits to make sure the products that they are deducting for are actually coming back and being credited.

The old way to solve the problem of returns is the long process, which takes up to several weeks to a month. When returns are coming back constantly from suppliers, companies will wait a quarter or two to consolidate all of the data because they often are returns in transit. They will go ahead and do a reconciliation against the A/R credits. So you'll have the retailer's debits, and your credits of what your warehouses process, and who knows how accurate your warehouse is.

Once they have the debits and credits, they will go ahead and create a returns variances analysis. That analysis can be huge in terms of size, because if you're waiting for a quarter or two of data, it's going to be quite complex to go through everything. At the end of that process, you're going to go ahead and provide that to the retailer, and then the negotiations begin. Because of pricing variances, shortages, and overages, they may actually return more to you. There's freight, handling fees, and a myriad of different variables that creates the complexity for returns in the old way retailers used to settle.

Now, retailers want everybody who's supplying them to dispute each return. They don't want to settle, they want you to do the return reconciliation, but they also want you to dispute and upload at a line-by-line level. Now you're actually doing their work for them. Using their portal means they don't want to talk to you or negotiate. The longer it takes you, the longer they are holding onto your cash flow, and they say “thank you very much for the cash flow” they're receiving.

Navigating Amazon Vendor Central is complex as returns from different date ranges are compiled together. What makes it even worse is the pricing, and the Amazon returning product at the wrong price. Whenever your company has a special, such as a holiday special, and the unit price has dropped down and it's a one-way sale, unfortunately often Amazon will just take all the product. They won't specifically tag it as a one-way sale, so even though you may give them a deep discount and said there are no returns allowed, there are still instances where that product comes back for various reasons.

What makes things even more complicated are MDF's and Co-Op agreements that are in place. Not only are they doing the unit and pricing variants, but they're having you incorporate the MDF agreements on the last one. They’ve made it very difficult to use their portals. You need the agreement number, the invoice numbers that they're associated with, and product lines, for each and every single line item. It is very time consuming, and returns have always been painful.

What's involved with a returns reconciliation and why? Is it bigger now than in the past? Yes, because they're requiring line by line resolution, rather than a quarterly analysis where you can write macros to look for the information. When it comes to the speed on the invoices, they may or may not pay you on terms, but on a return, once it leaves their warehouse or they credit the end user, they immediately take your money. They may drag their feet paying you, but when it comes to returns, you're short.

Real money flows in and out of the supplier, and they're moving a lot of their suppliers to EFT, so they're able to take that money immediately, which helps with their cash flow, not necessarily yours. You can dispute the whole entire return, or you can dispute it by ASINs (Amazon Standard Identification Number), but if you dispute by ASIN then you must select a reason for it. Not only do you have to enter the information, but you need to validate each and every line item. Previously, you could group product together for shortages, but unfortunately those days are gone.

A company we’re helping out has over 200,000 returns per year. On average that's five to seven line items per return. If you multiply that average by seven, you're looking at 1.4 million line items that they're going through on an annual basis. They have to do each return one by one, put it into their portal, and wait for payment. Return reconciliations have consumed an entire department who is in constant firefighting mode. They're always trying to get ahead of the returns. There's also time length associated with them, meaning if you don't dispute within a specific time period, you're instantly out the money.

Traditional solutions don't work as well as they once did. You can add temps to throw bodies at the problem, but that's going to cost you more money. Often companies will weigh their pros and cons by saying, "If it's a small variance of anything less than $25," or whatever the threshold is, they're not going to dispute that. You're going to have to do some of that work if you really want the money. You could throw cheaper bodies at the problem by hiring offshore, but that's a temporary solution. You're still going to have to do the work, and it can be seasonal and increased or decreased depending upon the time of year.

There are AF systems that process data by organizing the data for you in a better way, but bodies are still needed to tackle the problem. Somebody is going to have to review and enter that information into the portal for you. The simple truth is you can't ever win. In the world of returns and retailers, they have the technology, time, and money. In fact, they invest a lot of money in technology.

This is why you need some really high-tech bots called RPA, or Robotic Process Automation. How this works is robots automate business interactions by repeating a set of actions normally performed by humans. Robots are able to enter information line by line, and free of any 10 key errors. The software for robots can be combined with Artificial Intelligence, and you have a workforce of technology that's going to fight and level the playing field.

Technology is not just a bigger stick. It's a totally different way of dealing with returns.

No longer do you need masses of teams processing, but instead can fight fire with fire with bots that can check and dispute every return. You no longer need thresholds, because you have a team of bots doing the work for you, that also keep up and stay current.

The top benefit of robots in the return process automation is cost. It's about the bottom line. Bots are one sixth the cost of people. I'm not saying let go of the people, but rather, who wouldn't want six additional people on their team to help with their returns? If you have the bots doing the work for you, your team can actually focus on analytics of the data, and find root causes. Bots are much faster than humans and definitely cost a lot less.

The next benefit of robots is their ability to scale up and down. Christmas is still 6+ months away, but it is the season. What percentage of people in manufacturing A/R groups quietly sob in the months leading up to the holidays?

Everyone is excited about the holidays, but we also know that right after the holidays or during the holiday season, returns are going to come back, and the stress level for your team increases. Bots don't care whether it's December, January, March, or whenever those returns are going to come back. Another benefit of having a bots is hiring costs are minimal and a one-time fee. Once you have that return bot working, they're always there working at a minimal cost.

They can replicate very easily, so they can handle high volume. You can have one or two or however many bots you need working. If the volume increases, the number of bots can increase. You don't have to hire and train temps just to keep up with the volume. No tea breaks, no coffee breaks, no time off, and no worry about overtime with bots.

CIO's who are seeking to inject great efficiencies in their business actually love bots. They see their software automate basic tasks and catching hold of large enterprises. The Credit and Accounts Receivable area is a little behind compared to Accounts Payable. Some of the Accounts Payable areas are definitely using robots process automation. So often we think, "Wow, it's an IT project, it's going to take a lot of time to go through this, it's going to be a year, and it's going to cost me 3.5 million dollars." CIOs are realizing that RPA are not long projects, and if it's focused by bot, it can be done much quicker and at a fraction of the cost.

Another benefit is “bots as a service.” You've heard software as a service (SaaS.) In a typical consulting project, you have a senior practice lead from your organization, or Project Manager, Process Analyst Consultant, etc. You'll have a bunch of people that are on-site consulting and doing the business analysis, finding a functional document and so forth. The best people who know the process are your own people who do it day in day out. Each company has a different way of dealing with returns because of different systems and limitations. You're seeing more companies moving to a SaaS and utilizing the core team they have, instead of paying a bunch of consultants a lot of money.

It's easier than you think to walk a robot service provider through your process. Your team is the subject matter experts who can provide the raw data for the different systems needed to get the information from. IT can help you coordinate and it’s not a big effort. There's a lot of these feeds coming into your A/R or ERP systems on a daily basis. Now that bot service provider will go away, take the requirements, customize it to that specific bot, test it, and it's good to go.

Now the good thing about when a SaaS company signs up, if there are any changes to a retailer's portal, it's up to the SaaS company to make sure that the bots are continually working

and make those changes. You don't have to go back to your IT department and say, "Hey, by the way, it's not working." It's the responsibility of that service provider is to make sure that it's good to go and you're able to continue to work that process as it's been designed.

How do you get there? Schedule a demo of how robots and the process works, and see if it’s right for you. Make sure the service provider understands the business process, and that they have expertise with RPA. Come up with an integration plan and a road map, on board, and train. Again, the training is as easy as looking at the exceptions, because if the bots are going to do the work for you, they’re dealing with the exceptions. If they stop working, it should be the responsibility of the service provider to recognize and fix it.

I know you're constantly putting out fires, but you don't have to let issues and fragmentation dominate your strategic vision. Focus on one area, and take care of that one process instead of trying to conquer the ocean.

You may ask, "How long do you think it would take for a full implementation?" There's not a lot of IT involvement, because somebody's not building a system for all of the data to be stored in a single place. What it's doing is gathering, analyzing, reconciling, and uploading information. You don’t have to go to your project committee and say, "I'm going to need 250,000 to a million dollars for this project just to automate it."

Final piece of advice on robots and returns, is to focus on your department and your issues. Implement bots to solve a specific returns problem. If you have pricing issues, then that's the first one you need to go after. If it's shortages, or if it's something with the carriers, be specific to the problem itself. Don't try and solve your issues with a larger outsource RPA effort driven by a technology team. A lot of companies are now having internal RPA departments and trying to figure out what that is. They're putting a huge roadmap together and saying, "Let's see what we can do, let's make sure we have a good business case," and so forth. It can be done, but I don't recommend that. It’s better to focus on your area and then build on those bots. And don't be fooled by an all-in-one Accounts Receivable package.

There are also SAP’s out there, which is great, but if it's more accounting and manufacturing, you probably use the ERP system, and they're bolt on and say they can do everything. Typically they can store all of that data in a centralized place because teams may be reconciling in Excel or elsewhere. What I've seen work best is when the bots do the end-to-end process, and your teams deal with the exceptions. Instead of having to go into a bolt on and say, "I've got a return now, I've got to do the reconciliation, figure it out and do all my paperwork and documentation I need to upload it," find companies that do the end-to-end process that will free up your team's time to focus on the root cause issues.

A lot of these companies are good at putting the software together, which is great as a SaaS, but make sure your solutions provider has industry knowledge in returns processing.

Q & A SESSION

RVCF: Does my IT group need to be involved if I want to implement robots for returns processing?

Rohit Patel: Yes and no. They don't need to be involved in programming it. All they need to be involved in is the initial stage of being able to get access points to the credits, debits, invoices if needed, and the warehouse information. If they have that information, and they typically already have those feeds, it's just getting access. As a SaaS company, they should do all the heavy lifting and the programming. It's not your IT department.

RVCF: Is RPA like scraping or macros?

Rohit Patel: Without getting too technical, macros and scripts are basically programming, and they're short sequences of code that do one task or a series of tasks. Macros are linear and fixed. You may have already done that in Excel spreadsheets. It's linear and fixed through there. RPA bots are dynamic, and they're also system agnostic. When you write a macro it's going to be in Excel, and when you write a script, it's in an ARP system. Whereas RPA is system agnostic, and easily used not only on your systems but also with in the portal.

RVCF: What does the typical implementation process look like?

Rohit Patel: The typical implementation process is once you've identified the return issue that you need, it's probably a 30-60 minute call that's recorded of the process on how your team would go ahead and go through a returns process. Then the SaaS provider will build the bots, based upon the recording. They'll test it out, come back and say, "Here's what we built and what the bots are doing. You go ahead and tweak it, test it, make sure it's working correctly." And then it's live in production. Often companies will monitor that for a month before they fully trust the bots, to make sure it's working. But the whole implementation component is about two months.