We’re facing significant challenges migrating travel expense categories from our legacy system to SAP S/4HANA 2020. Our legacy system has 340 expense category codes that evolved over 15 years, including many custom categories for specific business units and regional requirements.
The standard S/4HANA travel expense types don’t align well with our legacy structure. For example, we have separate codes for domestic hotel (HTLD), international hotel (HTLI), extended stay hotel (HTLE), and training venue hotel (HTLT), while S/4HANA uses a single hotel expense type with qualifiers.
Here’s a sample of the mapping complexity:
Legacy: MEAL_BRK_NA -> S/4: MEAL (Breakfast, North America)
Legacy: MEAL_LUN_EU -> S/4: MEAL (Lunch, Europe)
Legacy: TAXI_LOCAL -> S/4: TRANS (Local Taxi)
Legacy: RIDE_UBER -> S/4: TRANS (Rideshare)
We’re considering creating a custom Z-table to maintain the legacy code relationships for historical reporting, but I’m worried this will create long-term maintenance issues. We also need to update our reporting logic to aggregate the granular legacy categories into S/4HANA’s broader expense types. Has anyone dealt with similar category mapping complexity? What approach worked best for maintaining reporting continuity while adopting standard S/4HANA structures?
Have you looked at using S/4HANA’s expense type variants? You can define regional or business-unit-specific variants that provide more granularity than the standard types, without going fully custom. This might let you preserve some of your legacy category distinctions while staying within standard SAP configuration. The variants are supported in standard reporting and don’t require Z-tables.
Interesting approach. How did you handle the reporting logic update? Our finance team has dozens of existing reports that filter and aggregate by the specific legacy codes. Did you rebuild all those reports, or did you create some kind of mapping layer in your reporting tool?
We had a similar situation with 280 legacy expense codes. We took the approach of mapping everything to standard S/4HANA expense types and using the additional text fields to capture the legacy category details. This kept our configuration standard while preserving the information needed for historical comparisons. The reporting was more complex initially, but it paid off in reduced customization maintenance.
Don’t forget about data quality during the mapping process. With 340 legacy codes consolidating to fewer S/4HANA types, you’ll lose granularity. Make sure your business stakeholders understand which distinctions are being collapsed and how it affects their analysis. We found that some “critical” legacy categories were actually used inconsistently and the mapping exercise revealed data quality issues that needed cleaning before migration.
For reporting logic updates, we built a conversion view in BW that mapped old category codes to new S/4HANA expense types. The view sits between the S/4HANA data source and our existing reports, so the reports themselves didn’t need to change. Historical data keeps its legacy codes in archived tables, while new data uses standard S/4HANA types. The conversion view handles the translation dynamically based on the posting date. This gave us reporting continuity without customizing the S/4HANA expense configuration itself.