Division of labour

A Digital Employee for Retailer Deductions, and What Your Analyst Still Owns

The short answer

Roy is a digital employee from ROIAI One that does the working half of a retailer deduction case: opening the case, reading and normalizing the retailer's reason code, pulling the evidence, testing the claim against that evidence, working out the root cause, and assembling the dispute packet. Your deduction analyst keeps the judgment half: whether a deduction is genuinely valid, what the retailer relationship can bear, which upstream process to fix, and which reason codes are trusted enough to submit without a look. Review is selective and exception-based, and it is carried by ROIAI One's own analysts rather than your team. This is a division of labour, not a replacement.

  • Roy does the work of the case.

    Opening it, normalizing the reason code, pulling evidence, testing the claim, determining root cause, and assembling the packet.

  • ROIAI One's analysts review the exceptions.

    The review burden is ours, and it is selective and exception-based rather than a queue anyone works through.

  • Your analyst keeps the judgment and the relationship.

    What is worth pressing, what to concede, what to fix upstream, and which reason codes to trust.

The distinction

A Digital Employee, Not a Tool

The distinction is simple. A tool waits to be operated. You open it, you tell it what to do, you do the work through it, and when you close it nothing continues. An employee is given a job. Deductions arrive, and the job gets done without someone driving each step.

Roy is given the job. A deduction lands, a case opens, and the case is worked. That is the whole of the distinction, and it is worth stating plainly. Most software sold into a deduction team is a tool wearing the language of an employee: a queue, a dashboard, a workflow builder, each of which still leaves your analyst doing the work.

A tool waits to be operated

  • You open it before anything happens.
  • You tell it what to do, step by step.
  • The work still passes through your analyst.
  • Close it and nothing continues.

An employee is given a job

  • A deduction lands and a case opens.
  • The case is worked without someone driving each step.
  • Your analyst is consulted, not operated through.
  • The job carries on between logins.
Step by step

Who Does What

Below is the actual sequence of a retailer deduction case, and who does each step. The fourth column is ROIAI One's own analyst, because part of the answer to “who does this work” is “us”. Presenting the split as only Roy versus you would be dishonest.

The sequence of a retailer deduction case, showing for each step what Roy does, what your deduction analyst does, and what an ROIAI One analyst does.
The stepWhat Roy doesWhat your analyst doesWhat an ROIAI One analyst does
A deduction arrives and a case opensOpens the case from the deduction, whether it came through a connected system or was forwarded to Roy as a notice by email.Nothing. This step comes off your analyst's desk entirely.Configures the intake path for your account before the first case, and does so per account rather than it being self-serve.
The reason code is read and normalizedReads the retailer's own reason code and maps it onto a common taxonomy. The mapping is deterministic and fails closed: a code Roy cannot map is written as unmapped and flagged for human review rather than guessed.Nothing on a code Roy maps. Your analyst no longer has to hold each retailer's private code vocabulary in their head.Reviews the codes Roy flags as unmappable.
Evidence is pulledPulls the evidence the case needs: the invoice audit trail, item price history, unit reconciliation across carton and per-unit pricing, EDI evidence, and the documents attached to the case.Nothing, on a connected account. On an account with no connected system, your analyst forwards or uploads the documents, because Roy can only work from what it has been given.Nothing routine.
The claim is tested against the evidenceEstablishes what the record actually says, for example the agreed price from the invoice audit trail and price history, and tests the retailer's claim against it.Nothing routine.Nothing routine.
A root cause is determinedBuilds a decision tree of candidate causes, eliminates each against the evidence, marks hypotheses confirmed or ruled out, and ranks what survives by originating party and entity type, with the recommended corrective actions.Nothing. This is the step your analyst most often skips, because there is never time for it.Reviews the root-cause analysis before it is released to your account. This is a deliberate gate.
The dispute packet is assembledAssembles the packet: the claim, the evidence, and the argument.Nothing.Nothing routine.
The packet is reviewedPresents the packet, and surfaces the cases it has flagged rather than presenting every case as equal.Nothing routine. Review is not your team's burden.Reviews the exceptions that need judgment. Review is selective and exception-based.
The packet is filedFiles the packet. Auto-submission is off by default for every reason code.Decides whether to enable auto-submission for a given reason code, and can reverse that decision.Releases the packet on any reason code where auto-submission has not been enabled.
The outcome is recordedRecords the outcome against the case.Reads the outcome and decides what it means commercially.Nothing routine.
Scope

What Roy Does Not Do

Roy works one lane: retailer deductions and chargeback disputes. The following sit outside that lane, as a matter of scope rather than apology.

  • Roy does not give you a root-cause dashboard or trend analytics. There is no view where you slice deductions by root cause or watch a trend across periods. That is not built.

  • Roy does not close the loop so that deductions shrink over time. Roy identifies the cause and names the corrective actions, and those recommendations are produced for a person to act on. Nothing reads your edits or your fixes back into the pipeline. Making the change is operational work on your side, in your warehouse, with your third-party logistics provider, or in your order process.

  • Roy does not accept a forwarded chargeback from any retailer. One retailer's notice format is handled on the forwarded-notice path today, and ROIAI One configures that path per account.

  • Roy does not do pre-invoice price-mismatch prevention. Roy establishes the agreed price and disputes a price deduction that has already landed. Catching a mismatch between the purchase-order price and the invoice price before it becomes a deduction is a separate capability and is not built.

  • Roy does not audit pricing, chase freight bills, or manage returns. Those are adjacent finance functions and they are not this lane.

Yours to keep

What Your Analyst Still Owns

Your deduction analyst keeps every part of the job that requires a judgment about your business, your customer, or your risk. Specifically:

  • Commercial judgment and the retailer relationship.

    What you are willing to press, what you are willing to concede, and what a given account can absorb without damage is a commercial decision that sits with your team.

  • The decision to accept a deduction as valid.

    Some deductions are correct. Deciding that a deduction is one of them, and that the right move is to take it rather than fight it, is your analyst's call.

  • The exceptions Roy flags.

    A reason code Roy cannot map onto the taxonomy is written as unmapped and surfaced rather than guessed. Where the exception concerns your business rather than the dispute mechanics, it is your analyst who resolves it.

  • Fixing the upstream process Roy identifies.

    Roy can name the originating party and the corrective action. Changing a pick process, renegotiating a routing arrangement, or correcting an order-entry practice is work only your organisation can do.

  • The decision to enable auto-submission for a reason code.

    This is a deliberate change your team makes, per reason code, and can reverse.

The review model

How Review Actually Works

Review is selective and exception-based. ROIAI One's own analysts review the exceptions that need judgment, not the customer's team. Auto-submission is off by default for every reason code, and enabling it for a given reason code is a deliberate change the customer makes and can reverse.

That statement does two jobs at once. The review burden is ours. The boundary of what proceeds without a look is yours to set.

The default state

Every reason code starts with auto-submission off. On those codes, a packet is released for filing by an ROIAI One analyst. Your team is not in that loop.

Reversible

The enabled state

A reason code moves to auto-submission only when your team deliberately enables it for that code, once you are satisfied with how the code has been handled. It applies to that code and no other. You can turn it back off.

The progression is per reason code by design. A code where the evidence is unambiguous and the pattern is stable is a different risk from a code where it is not, and treating them identically in either direction would be wrong.

The shift

What Changes for Your Team

Work that leaves the desk

The work that leaves your analyst's desk is the volume work: reading each retailer's private reason-code vocabulary, retrieving the same evidence for the hundredth time, reconstructing what the invoice actually said, and assembling the packet. That work does not require your analyst's judgment. It requires their hours.

Work that stays

The work that stays is the work that was always the reason you employ an analyst rather than a clerk: deciding what is worth fighting, deciding what to concede, holding the retailer relationship, and fixing the thing upstream that keeps producing the deduction. Today that work is usually the first thing to get cut, because packet assembly consumes the day and root-cause work has no deadline attached to it.

Work that was not happening at all

There is also a category of work that was not being done at all. Most deduction teams have never had capacity for per-case root-cause analysis. Your analyst was not doing it badly. The case volume made it impossible to do at all.

Questions

Frequently Asked Questions

Is Roy replacing my deduction analyst?

No. Roy does the working half of a retailer deduction case: opening it, normalizing the retailer's reason code, pulling evidence, testing the claim, determining root cause, and assembling the dispute packet. Your deduction analyst keeps the judgment half: whether a deduction is genuinely valid, what the retailer relationship can bear, which upstream process to fix, and whether to enable auto-submission for a given reason code. The division is between execution and judgment, not between a person and a replacement.

What is the difference between a digital employee and deduction software?

Software is a tool that waits to be operated: your analyst still does the work, through the tool. A digital employee is given the job. With ROIAI One, a deduction arrives, a case opens, and Roy works the case through evidence retrieval, testing, root-cause determination, and packet assembly, rather than presenting your analyst with a queue to work through.

Does a person review a dispute before it is filed?

Review is selective and exception-based. ROIAI One's own analysts review the exceptions that need judgment, not the customer's team. Auto-submission is off by default for every reason code, and enabling it for a given reason code is a deliberate change the customer makes and can reverse. So a person is in the loop on every reason code by default, and remains in the loop on any code where your team has not enabled auto-submission.

Who decides which reason codes are submitted without a review step?

The customer does. Auto-submission is off by default for every reason code. Enabling it for a given reason code is a deliberate change the customer makes, it applies only to that code, and it can be reversed.

Does Roy tell me why the same deduction keeps happening?

On a case, yes. Roy builds a decision tree of candidate causes, eliminates each against the evidence, and ranks what survives by originating party and entity type, along with the corrective actions that would prevent recurrence. An ROIAI One analyst reviews that analysis before it reaches your account. What Roy does not provide is a dashboard or a trend view across your deduction book, and it does not close the loop for you: acting on the corrective action is operational work in your warehouse, with your logistics provider, or in your order process.

What stays with my analyst because Roy will not pick it up?

Everything outside the one lane Roy works, which is retailer deductions and chargeback disputes. Roy does not provide a root-cause dashboard or trend analytics across your deduction book, so reading the book as a whole stays with your analyst. It does not close the loop so that deductions shrink on their own, so the corrective action stays operational work on your side. It does not accept forwarded chargeback notices from every retailer, as one retailer's notice format is handled on that path today and is configured per account. It does not catch a purchase-order to invoice price mismatch before it becomes a deduction. Pricing audits, freight bills, and returns sit outside the lane entirely.

What happens if Roy cannot read a retailer's reason code?

It is flagged rather than guessed. Reason-code normalization is deterministic and fails closed: a code Roy cannot map onto the common taxonomy is recorded as unmapped and marked for human review. Roy does not infer a mapping it cannot make.

See the Split Against Your Own Deductions

The division of labour is easier to judge on your own book than in the abstract. A Chargeback Recovery Assessment reads your deduction data and shows what is disputable, what is dilution, and which reason codes recur.