Analyse Kaufland returns: Check statuses and return reasons with AI

You can identify open Kaufland returns through the processing status of each return unit. Add the parcel status and match each return unit to its ordered unit. To analyse return reasons, instead count all return units created during a defined period, including cases that have already been processed. This gives you a worklist and an overview of the reported reasons.

Backlane can retrieve authorised Kaufland data in your AI chat using read-only queries. The Backlane documentation explains the connection; the practical guide to marketplace analysis with AI covers the basics of interpreting results. The two prompts here are templates and have not been run against a merchant account. The example is entirely fictional.

Which returns can the analysis actually cover?

The analysis covers the return records available through your connection. Kaufland describes automatic return creation for sellers using DHL Return Labels, DPD Return Labels or Kaufland Shipment Solutions. First check which of your returns are actually captured in that process. The official returns documentation explains this requirement.

A successful query with no results means “no matching records found”. It does not prove that your entire business has had no returns. Specify the seller account, the Kaufland country marketplace (storefront, such as de) and the fulfilment method. Report missing permissions or an interrupted retrieval as such.

What is the difference between a return, a return unit and an order unit?

A return contains the return shipment process, including parcel status and tracking details where available. Its identifier is id_return. A return unit describes one item to be returned, with its own processing status and return reason. It has the identifier id_return_unit and refers to the ordered unit through id_order_unit.

Do not add counts from these three levels together. A return with three return units is one case containing three units. When analysing reasons, count each unique return unit once. Use the order unit only to identify the product; a similar product title is not enough. The fields are described for returns, return-units and order-units in the Kaufland endpoint documentation.

What does each status mean for the next check?

The parcel status tells you where the return shipment process stands. The unit status tells you how the individual item has been processed. A parcel that has arrived is not yet an accepted return unit.

Level	Status	Meaning	Next check
Return	return_requested, label_generated	Return requested or label created, respectively.	Is there already evidence of dispatch?
Return	package_sent	Parcel reported as sent.	Check available tracking data.
Return	package_received	Parcel reported as received.	Check the processing status of the units it contains.
Unit	need_to_be_returned	The unit is to be returned.	Compare parcel status and any goods-receipt record.
Unit	return_arrived	Return unit reported as arrived.	Clarify the goods inspection and next processing step.
Unit	return_in_clarification, return_in_repair	Clarification or repair is in progress.	Check responsibility and the next internal step.
Unit	return_accepted, return_rejected, return_closed	Accepted, rejected or closed, respectively.	Check the specific outcome if needed; keep these values distinct.

label_deleted describes a deleted return label. That alone establishes neither that the goods have arrived nor that every related unit has been completed. The status values are listed in the endpoint specification. Making a change or issuing a refund is a separate task and is outside the read-only check below.

How do you get a list of cases that still need checking?

Start with return units that still need processing. Restricting the query to “created this week” would hide older open cases. Retrieve every result page within the agreed scope, then look up the related returns by their identifiers.

Check the Kaufland connection [Connection name], storefront
[Country code], fulfilment method [fulfillment_type], using
read-only queries. Do not change data or send messages.

Read return-units with the statuses need_to_be_returned,
return_arrived, return_in_clarification and return_in_repair.
Do not set a lower creation-date limit: older open cases
belong in the result too. Read every result page using
limit and offset; count each id_return_unit only once.

Add the return status for each unique id_return.
Show id_return_unit, id_return, id_order_unit, unit status,
return status, creation date and next check.
Do not show customer names, addresses, contact details or free-text notes.

Group by arrived, in clarification, in repair and still to be
returned; sort each group by creation date, oldest first.
Do not infer a missed binding deadline from the age of a record.
State retrieval time, source, scope and completeness.
Explicitly flag missing matches and retrieval errors.

The creation date here shows the age of the record. It does not tell you exactly how long the current status has applied. A list based on binding processing deadlines also requires the relevant deadline and evidence of when its clock started.

How do you analyse return reasons meaningfully?

For reasons, use a fixed period based on the creation date of the return unit. Include every processing status: counting only open cases would exclude returns that were resolved quickly.

reason contains a reported reason such as wrong_size, defect or misleading_description. The code no_reason means no reason was provided. Keep it distinct from a missing or unknown data value. A reported defect is initially an assertion within the return process; it does not replace an inspection of the goods.

Analyse the Kaufland return units for connection [Connection name],
storefront [Country code], fulfilment method [fulfillment_type],
using read-only queries. Period: [Start date] at 00:00 inclusive
to [End date] at 00:00 exclusive, Europe/Berlin.

State the converted time boundaries first. Select return-units
by ts_created_iso, without a status filter. Retrieve them using
ts_created_from_iso with a small overlap, then restrict the
results precisely to both time boundaries.
Read all pages and count each id_return_unit only once.

Group by reason and show the count and distribution of current
unit statuses. Keep no_reason separate from missing or unknown
values. Show the total count, retrieval time and any data gaps.
Do not calculate a return rate.

Create a question to investigate for each of the two most common
specific reasons. Do not claim a confirmed cause. Do not display
customer or address data or free-text notes. Do not change anything.

The query provides a lower creation-date boundary; the upper boundary is checked afterwards against the returned timestamps. Pagination prevents the first page alone from being treated as the complete analysis.

What does a useful analysis look like in a seller’s daily work?

Entirely fictional example: For a completed month, you find 20 return units: eight with wrong_size, five with defect, four with no_reason and three with dislike. Six currently have the status return_arrived. Those six belong in the operational review. The eight size-related reports justify a separate check of the affected variants and sizing information.

For that second step, match the return units to products through id_order_unit. Keep missing matches visible. Only then can you check whether size-related reports are concentrated on a particular variant.

The 20 units are not a return rate, nor do they automatically represent 20 items that have arrived. A rate also needs suitable sales or shipment quantities, a clear definition and a comparable time basis. A reliable worklist is enough for the daily check; reported reasons are the starting point for investigating causes.