Independent IFS Cloud practice · Customer orders
Customer returns in IFS Cloud: how the RMA flow works and where it stalls
A Return Material Authorization (RMA) is the IFS Cloud record of a customer's request to send delivered parts back. It controls three things at once: whether you accept the return, whether the parts re-enter stock or are scrapped, and whether and when the customer gets a credit. The gaps between its steps are where a return goes wrong: released but never received, received but never credited, credited at a price nobody expected.
Key takeaways
- An RMA has a header and one or more lines. Per the 25R2 documentation, the statuses are Planned, Released, Partially Received, Received, Completed, Cancelled and Denied, and the line status shows the real state of each line.
- A coordinator, not the warehouse, decides whether a return is accepted: they release, deny or cancel a Planned RMA. Releasing is what unlocks the return note, receiving and the credit.
- The price on the credit depends on what the line is linked to: the customer order, the debit invoice, or nothing. With no link the price defaults to zero and someone has to enter it.
- Returned parts either go back to inventory through Register Arrival or are scrapped, and scrapping requires a scrapping cause.
- The credit invoice can be created before the goods arrive. IFS leaves that sequence to the company, so it needs an explicit rule, not a habit.
1.What is an RMA in IFS Cloud, and what does it control?
An RMA records a customer's request to return parts that were already delivered. It works with a customer order number or without one, and it can issue the credit with or without a linked debit invoice. The documented reasons for returns are ordinary ones: damage, a shipment error, sampling.
It is built on two levels. You save the header first, and the RMA takes the status Planned. Then you add lines. A line can carry an inventory part, a non-inventory part or a package part, with the quantity the customer wants to send back, a return reason and, where it applies, the customer order and the debit invoice. The header status does not change as lines are added, so the line status is the one to read.
Three pieces of basic data have to exist before the first RMA is useful. Coordinators are the users who approve, deny or cancel returns, and each RMA is assigned one. Return reasons are codes with a description and an "Inspection Info" instruction that tells warehouse staff what to check. Scrapping causes are maintained in advance, and every scrap needs one. If the return reasons carry no Inspection Info, the warehouse gets no instruction on what to check.
2.How does a return move from request to credit?
The flow is short, but each step has an owner, and the owner is different at each step. That is where returns get lost. IFS assigns only the coordinator; the other roles in the table are the usual split of work.
| Step | Who acts | What the system does |
|---|---|---|
| Request entered | Customer service | The RMA is saved as Planned. Price and tax codes are taken by default from the linked order or invoice. |
| Release, deny or cancel | Coordinator | Release accepts the customer's request. After release you can print the return note, receive the parts, approve for credit and create the credit invoice. Cancelling closes the RMA. |
| Receive or scrap | Warehouse | Good parts are received through Register Arrival. Parts the customer scraps are closed with the Scrap command on the RMA line. |
| Credit | Finance or customer service | The credit invoice is produced from the RMA. It can be created and printed before the goods arrive, if the company chooses that flow. |
| Completed | Automatic | The RMA becomes Completed once every part is received or scrapped. |
Release can apply to all lines or only some of them, and the header moves to Released even if only some lines were released. A header showing Released therefore does not tell you that the whole return was accepted. Read the lines.
The step people underestimate is the first one after release. The coordinator has said yes, the customer has been told to send the goods back, and from that moment the RMA depends on a pallet arriving at a dock that has no idea it is expected. The return note is the document that closes this gap, and it is printed from the RMA after release.
3.Why does the credit sometimes not match the original invoice?
The price on an RMA line is not looked up from one place. The 25R2 documentation describes it as follows: with only a customer order linked, the price comes from the order. With a debit invoice linked, it comes from the invoice. With neither, the price is zero, with condition code pricing applying where it is defined. A price typed in by hand overrides all of these.
| Line is linked to | Price taken from | What to watch |
|---|---|---|
| Customer order only | The order line | Read the warning below the table. |
| Debit invoice | The invoice | Read the warning below the table. |
| Nothing | Zero by default | Someone must enter a price, or the credit is for nothing. |
| Manual price | What was typed | Overrides every other source, including a correct one. |
The documentation warns that changes made to a linked debit invoice may be lost, so the credit may not match the debit, and that tax changes made on an invoice may be lost when crediting. Check a credit against the invoice before it goes out.
Two more details matter to finance. Discounts are not handled separately: the net price is used and no contra discount account is created, so discounts can look larger in posting follow-up. And a separate customer can be set for the credit on the Return Handling Address tab, which must differ from the original customer.
The practical lesson is the one that applies to any price that the system takes from a record that may have changed: before you trust a credit, know which record the price came from.
4.Back to stock or to scrap: what happens to the parts?
Sorting comes first. Damaged parts should not be put back on the shelf only to be found later.
- Return to inventory - received on the Register Arrival page. A defect-free receipt sets the line to Return Completed or Partially Received, depending on whether all or some of the parts came back.
- Customer scraps the parts - the Scrap command on the RMA line, with a scrapping cause.
- You scrap them - receive through Register Arrival, then scrap through an inspection on the Receipt page or in inventory.
- Non-inventory parts - the line completes once all parts are received.
Two further behaviours are worth knowing before a go-live. If a returned part meets an existing shortage, IFS shows a message, but only when the system parameter Shortage Handling is set to Yes in Parameters for Distribution and Manufacturing and the Shortage Notification option is enabled on the inventory part. And for serial-tracked parts, the option Stop Creation of New Serials in RMA is enabled by default, which means a serial number that does not exist cannot be returned. The documentation allows creating new serials at return only when the RMA line is not connected to an order, and its wording on which setting permits that is ambiguous, so confirm the behaviour in your system before relying on it (serial tracking, 25R2).
A delivery registered by mistake is a different problem from a customer return. For that, reversing the delivery is the correct tool, as described in IFS Cloud Undo Customer Delivery.
5.What changes with package parts, suppliers and other sites?
The simple case is one part, one customer, one warehouse. The documentation also covers three variants that add steps, and two of them add a second record that someone has to watch: a purchase order receipt return, or a receipt RMA at another site.
- Package parts. You can select the package part, and all components are expected back, or add components as separate lines with their own quantities. Linking a customer order is required for package returns.
- Direct return to an external supplier. You set the supplier on the header, and each line must link to an order line that the supplier delivered directly. Registering the return creates a return record on the related purchase order receipt, treated as a credit return.
- Return to a different site, or to an internal supplier. You set Return to Site on the header. Releasing the originating RMA creates a receipt RMA at the other site, and the two reference each other's line numbers. Goods are received at the receiving site through Register Arrival, and the status of the originating RMA follows the receipt RMA.
When the return goes to another site, nobody at the demand site can receive anything on the originating RMA. If the receiving site does not act, the original stays open and looks like a customer who has not sent the goods back. It is the same pattern as a document sitting in a state that needs attention.
6.Where do returns stall in practice?
The statuses above make the stalling points visible. These are the combinations I would look for in a review of how a company runs returns. They are conclusions from the documented flow, not features IFS Cloud raises on its own.
| What you see | What it usually points to |
|---|---|
| RMA in Planned for days | No coordinator is acting on it. The customer is waiting for an answer and does not know that. |
| RMA Released, nothing received | The customer was told to return the goods and has not, or the dock does not know the return is coming. |
| Lines Received, credit not created | The parts are back in stock, but the customer is still waiting for the money. |
| Credit created, parts never received | The company chose to credit first and has no follow-up on the goods. |
| Lines with a price of zero | Orderless RMAs where nobody entered a price. |
| Originating RMA open, receipt RMA waiting at the other site | A transfer between sites that nobody at the receiving end has picked up. |
None of these is an error in IFS Cloud. Each is a valid state that is allowed to last as long as nobody looks. That is why a monthly review of open returns tends to find them too late, and why catching it at month end costs more than catching it in the week it happened.
7.How do you make returns reliable without customising IFS Cloud?
- Decide the credit rule once. Credit on release, credit on receipt, or credit after inspection. IFS allows each. The documentation says companies choose their own flow, so write yours down as a working rule for the coordinators.
- Keep return reasons and scrapping causes short and used. A list of forty reasons is a list nobody reads. The "Inspection Info" text on the reason is the cheapest instruction you can give the warehouse.
- Give each status a maximum age. Planned for more than two working days, Released for more than your agreed return window, Received without a credit. The numbers are yours to set. The point is that each state has an owner and a clock.
- Require a link to the order or invoice wherever you can. A linked line gets a price from a record. An orderless line gets zero or a typed number.
- Name the coordinator group, not a person. In reviews I have run, a return waiting for one person's holiday is a typical reason for Planned to last too long.
Rules three and five are monitoring rules, not configuration. They need a list of the RMAs that are past their limit, delivered to the person who owns the next step. The SCM Automation Pack does not ship an RMA rule today, so this would be a rule designed for your process. That is the case for routing exceptions to an owner instead of publishing a report, and it can be done as a read-only monitoring pattern that reads the standard projections and writes nothing back to IFS Cloud.
For the full description of every field and the multi-site variants, the primary source is the IFS Cloud documentation page Return Material Authorization (25R2). Behaviour can differ between releases, so check the page for the release you run.
8.Frequently asked questions
Can I create an RMA without a customer order in IFS Cloud?
Yes. The RMA works with or without a customer order number, and the credit can be issued with or without a debit invoice. The cost is the price: an unlinked line has a price of zero by default, so a price must be entered manually. Package part returns are the exception, because they require a linked customer order.
Who can release or deny an RMA?
The coordinator assigned to it. A coordinator can release, deny or cancel a Planned RMA. Coordinators are maintained as basic data, with a coordinator ID, name, phone and coordinator group.
Is the credit invoice created when the goods arrive or before?
Either. The documentation states that the credit invoice is produced when returned parts are received, and also that it can be created and printed before the goods arrive, so each company chooses its own flow. If your policy is to credit only after receipt or inspection, that has to be a rule your coordinators follow, because the system does not enforce it for you.
How do I scrap returned parts?
It depends on who scraps them. If the customer scraps the parts, use the Scrap command on the RMA line. Otherwise, receive the parts through Register Arrival and scrap inventory parts through an inspection on the Receipt page or in inventory. A scrapping cause is required either way.
9.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Know which returns are waiting, and for whom
Tell me how returns run in your IFS Cloud today. On a 30-minute fit call I will walk through your coordinators, reasons and credit rule, and talk through how a read-only check could list the RMAs that are past their limit and send each one to the person who owns the next step. That check would be designed with you, not an existing rule.