The original unredacted version of this has been forwarded to eBay but I thought I would share it here as well.
While it might be long, it is well worth the read as this affects EVERYONE.
Transaction Report Errors, Omissions and Data Issues.
Please read this all the way through, examples are provided towards the end.
Accounting and Reconciliation are basic functions in any business. When tracking profit and loss all data is relevant, be it shipping costs, advertising costs, or selling fees. Sellers must be able to reconcile every transaction on eBay. They must be able to reconcile eBay system data with their own internal system data at the individual item detail level. Data is critical for reporting, not only for information as a Seller, but for reporting to local municipalities, State Tax Revenue Departments, and the Internal Revenue Service.
I was excited to see the development of the Transaction Report with the implementation of Managed Payments. Data we have never had access to in the past, is now available. The problem is being able to take advantage of and use the data you have spent time and development costs with implementing this report.
I expected the Transaction Report to eventually remove the need for additional data manipulation and File Exchange downloads to compliment the Invoice data. It did not. I anticipated the Transaction Report would go through a few iterations from its original release and be debugged and enhanced as eBay Managed Payments conversion rates increased. While there have been some improvements and additional information added since the initial release, basic information is still not being provided in a format that is helpful to Sellers. In some cases, the information is not provided at all.
eBay is now going to remove the Invoice process completely (including the reporting) due to real time charges and we have been told the solution to replicate the data on the Invoices is the Transaction Report.
This change was announced on March 3, 2021. This is from the Seller Update notice. “Eventually, you will no longer receive a monthly billing invoice, but depending on your monthly invoice date, you may continue to receive invoices for both March and April.”
This is not a minor change. This change affects every single Seller. Any Seller that currently reconciles to their invoice data now must build a completely new process to accommodate the Transaction Report and the loss of the Invoices. This is something that should have been given with plenty of notice to allow Sellers’s time to adapt to the change. Less than one months’ notice is inexcusable when you are talking about removing critical reporting functionality that affects transactional and financial reporting.
I am sending this document to show why the Transaction Report in its current format is not an adequate solution to the current Invoice reporting for Sellers at any level that reconcile their accounts. Sellers are now no longer going to have any type of aggregated data at their disposal, they are going to need a report that allows them to easily reconcile at the level they have been able to in the past using the Invoice, as well as provide accurate totals.
I have spent some time over the last couple of days identifying some issues with the Transaction Report in its current format in the hopes that this could be forwarded to someone on the Technical side of the reporting team so that some simple changes could be implemented that would make the conversion process from Invoices to No Invoices smoother and more manageable, not only for the Seller, but also for eBay as eBay will be the one bearing the brunt of complaints and customer service calls.
Every transaction within the eBay system is tied to the Item ID Number. That is the Primary Key for everything we view online, for the current invoice, for File Exchange uploads and downloads, calls to Customer Service, paying Taxes, verifying profit, EVERYTHING.
When it comes to the Transaction Report, in many cases the Item ID is not provided, is merged with other extraneous data, or requires manipulation. With the current Invoice CSV file, both the Order ID and the Item ID are on the invoice each in their own field. For every transactional charge on an invoice the Item ID is provided for that charge. The Item ID is the primary key for data on the PDF invoice.
While Order ID can be useful, I can have two Items in an order from two completely different sourcing locations or distributers. I must be able to tie an individual inventory item and the subsequent sale data to a procurement cost for each item. This is a basic part of business. There is also no Order Id assigned until a sale happens, so for some transactions, there never is an Order Number (Insertion fees would be one example)
To keep this document somewhat easy to read I have removed extraneous fields from the report in the below examples and only kept the relevant fields to the identified issue visible for review. I have also removed any PII data.
TYPE – ORDER (non-combined)
This has everything I need to be able to reconcile, all necessary and fields are populated. There is no manipulation with this Order record type. I can tie everything together from taxes to the processing fees at the Item level. I have the Order ID AND the Item ID.
TYPE - SHIPPING LABEL – (Non-Combined Order)
I was very happy to see this data added on the Transaction Report, finally, eBay was reporting shipping costs on a report vs having to manually scrape shipping costs. Unfortunately, the information is not in a format that is useful without a whole lot of manipulation. It is still quicker now to scrape shipping data from the website.
The [Item ID] Field is blank. There is no way for me to tie this label or cost to an individual Item without having to manipulate data within the report.
On this record type, the Item ID is included in the [Order Number] Field. The Item ID number is merged with the actual Legacy Order ID and not the true current Order Number. The Legacy Order ID is only visible on eBay on the transaction level data under the Payments Tab, nowhere else. The Legacy Order ID number is not searchable anywhere else in the system. I have to strip out the extra data to get the Item ID and add it to the record to reconcile. While I can do this easily via manipulation, the average Seller has no idea how to do this.
The other option is to manually go look up the Shipping Label on the eBay online view, identify the Item ID and then add the Item ID to the record so I can reconcile and track profit.
Example of non-combined Order Shipping Label.
The actual Order Number for the above Item is xxxxx.
Suggested Solution – Populate the [Item ID] field with the Item ID Number.
Shipping Label Fee for International transactions, UPS and FedEx.
How is this charge going to be populated on the transaction report? Will it include the Item ID? How will refunds (for cost adjustments) be shown?
Below is an example of a Shipping Label Fee for an eBay International Label Purchase. This is reported on the PDF invoice using the Item ID number.
Below is the same charge on the current CSV Invoice File. Again, this is listed by Item ID.
Verify that Shipping Label Fees for eBay international, FedEx and UPS include the Item ID on the Transaction Report.
TYPE - REFUNDS – Regular Order (non-Combined Order Refund)
The [Item ID] field is blank. The Item ID is included in the [Legacy Order ID] field, but it is combined with the Legacy Order ID. I have to manipulate the data and strip out the extra data to get the Item ID so that I can reconcile.
TYPE - REFUNDS – Cancelled Order
The [Item ID] field is blank, the [Legacy Order ID] has the Item ID number in the field merged with the Legacy Order ID that must be stripped.
Suggested Solution – Populate the [Item ID] field with the Item ID Number.
TYPE - CLAIM and HOLD
The [Item ID] field for both Types of Transactions are blank. [Legacy Order ID] has the Item ID number in the field merged with the Legacy Order ID that must be stripped.
The [Reason for hold] field is also blank on both transactions. This gives me no indication as to what the Hold or the Claim is for. If this field is not going to be populated, why is it included on a dataset report header?
Suggested Solution – Populate the [Item ID] field with the Item Number.
Populate the [Reason for hold] field.
TYPE - OTHER FEE – INSERTION FEE
The [Gross Transaction Amount] is blank for this fee. In the current format of the Transaction Report, except for combined orders (more on this later), the [Gross transaction] field is always populated.
With this Other Fee transaction type, if the [Gross Transaction Amount] Is not populated I cannot use this field to calculate totals for any charges. I now must use multiple fields to get calculated and accurate transaction costs.
If a Seller uses the [Gross Transaction Amount] to calculate their totals their amounts will be incorrect. Sellers are not going to know this and would not expect a field to not be populated for different transaction types this.
This will cause incorrect reporting for this and any other transaction types that are applied to the report using the same methodology.
Suggested Solution – populate the [Gross Transaction Amount] so that totals are correct when this field is aggregated.
Missing Data – Promotional Ad Fees
I am assuming that Type OTHER FEE and description would be populated for the Promotional Ad fee that is currently billed directly on the invoice? I have not had any sales with promoted listing fees so cannot verify this transaction type. This would also need to be a field where the [Item ID] needs to be populated with the correct data and not just with an Order Id or with merged data. The amount also needs to be included in the [Gross Transaction Amount] or it will cause the same accounting issues noted above in the Insertion fee above.
The current invoice lists Promoted Listing Fees of the item along with the ID and the amount. Note the Order Number is not provided currently.
The same requirements would apply for any extra fees for listing, Subtitles, Gallery images etc. The charges need to be reported correctly for accounting and the [Item ID] field needs to be populated.
COMBINED ORDERS
TYPE – ORDER (Combined)
When an order is combined it causes issues on the current invoice CSV Report and on the Transaction Report (examples provided below)
This is what the transaction report shows for a full combined order that included the initial purchase, a shipping label and then a shipping label refund because the order was combined. While this example shows a transaction where all transactions showed the same transaction date, there are many times when they are not all on the same date. A shipping label purchase or refund for a combined order might happen a few days later depending on purchase date and weekends or public holidays.
While the order does contain all the data, it is spread out over multiple lines. You aggregate the [Net Amount] and the [Gross Transaction amount] and the [Tax] at the order level but then break out the fees at the item level. The [Net Amount] and the [Gross Transaction Amount](s) are blank at the Item ID level and must be manually applied to track information at the transactional level. Is there a reason why the data has an additional line item at the order level? Note that the 30-cent processing fee is applied to one transaction, but at the Item Id level and not at the order level. The same for Sales Tax collected. This is at the Order Level and not at the Item ID level and must be accounted for.
Example of what is shown on the current PDF invoice.
TYPE - SHIPPING LABEL – Combined Order
On this type of order where the buyer has purchased multiple items the [Item ID] is blank, the [Legacy Order ID] is blank, and the [Order Number] is the populated with the actual Legacy Order Id.
While I understand that with a combined order there would not be an easy way to provide the Item IDs for a combined order shipping label, there is no way for me to tie this to an actual Item Id or even an Order Number.
I have to take the data in the [Order Number] field (which is actually the Legacy Order ID), search the transaction report for that Legacy Order number, find the corresponding true Order Number, search for that Order Number and THEN tie that to the Item IDs. Sounds confusing and time consuming? You bet!
Example showing the above shipping label record with the order data pasted below (both records are from the Transaction Report) showing the Legacy Order ID that is populated in the shipping label Order Number Field.
Suggested Solution – populate the [Order Number] with the actual Order Number and not the Legacy Order Number. If possible, find a way to not have the extra transaction line for the order. Break out the totals, taxes and aggregated charges to the item level.
REFUNDS – Combined Order
On a Combined Order refund the [Order Number] is at least displayed properly with the correct Order ID. The issue is that it shows one record, even when the refund is split across the order. The below refund was a shipping refund split over two transactions in a combined order. The system allowed me to apply this refund split across the order when I issued the refund. You track how much is applied to each item in case of when a future refund is applied to a specific item within the order, and you also show that on the refund email that is sent. Why can’t the refund be displayed on the transaction report correctly showing the two refunds, one for each Item ID as it is currently applied within the system?
Example Transaction Report Combined Refund that was split between two items.
Example of the email showing the refund split over the two items within the order.
Suggested Solution – Display refunds as issued against combined item IDs, if they are split across items in a combined order then there should be a record for each refund amount with the Item ID.
These are just the items I have identified so far. As additional line items that are currently only invoiced are added to the Transaction Report there may be additional similar issues to think about.
The bottom line is a transactional REPORT should NEVER require data manipulation. Required information should be present and displayed in the correct format with the correct data. Anyone reviewing a report should be able to reconcile that data back to a single transaction electronically on the system without having to manually manipulate data.
Aggregate totals should be able to be calculated without having to do different calculations on different fields based on the transaction type.
This cannot be done with the transaction report in the current format.
Key High-Level Issues.
Sellers cannot just filter or aggregate the available fields to get totals. Sellers have to manipulate data or calculate different fields based on the transaction type to get correct transaction totals.
Sellers cannot reconcile individual transactions without data manipulation.
Sellers cannot provide an accurate, original, non-manipulated data report to any external entity like a CPA or the IRS like they could with the Invoice PDF.
Sellers cannot reconcile or create adequate in-house detail reporting for themselves or their accountant without manipulating provided data.
I hope that this document is useful and helps eBay to understand the issues Sellers face with the removal of the invoice process and the addition of new transactional information on the Transaction Report.
