On this page
Summarize and analyze this article with
GLSU supports SAP S/4HANA in qualifying on-premise and private-cloud environments, but support depends on the S/4HANA edition, GLSU version and target system architecture. Current published requirements state that SAP S/4HANA Cloud Public Edition is not supported.
For organisations moving from SAP ECC, the important question is therefore not only whether GLSU can continue to operate. Finance and SAP teams should also assess whether its SAP-side transport, Windows desktop, Excel and SAP GUI requirements align with their intended S/4HANA operating model.
This is particularly relevant for organisations moving towards Fiori-led access, tighter clean-core governance and browser-based financial workflows. This article examines GLSU SAP S/4HANA compatibility and compares its operating model with Promenta’s SAP-integrated journal-management architecture.
Key Takeaways
- GLSU S/4HANA support extends to on-premise and private-cloud environments, subject to the relevant S/4HANA release, GLSU version, and system configuration.
- Current published requirements do not support SAP S/4HANA Cloud Public Edition.
- Existing customers moving to S/4HANA 1909 or later require at least GLSU 6.2c SAP/ABAP components.
- GLSU’s desktop operating model includes supported Microsoft Excel and SAP GUI components. The resulting SAP GUI dependency for GLSU should be considered by organisations planning Fiori-only or browser-led access.
- An S/4HANA migration should include retesting of templates, custom logic, authentication, connectivity, authorisations, validation and posting behaviour.
- Compatibility establishes whether a product can operate. Architecture, controls and user experience determine whether it remains the right strategic fit.
GLSU compatibility with SAP S/4HANA at a glance
| Deployment edition | Published GLSU support position | Principal consideration |
|---|---|---|
| SAP ECC | Supported | Established SAP-side transport, Excel add-in and desktop-client model |
| SAP S/4HANA On-Premise | Supported from release 1709 onwards | Existing customers using S/4HANA 1909 or later require at least GLSU 6.2c SAP/ABAP components |
| SAP S/4HANA Cloud Private Edition | Supported in applicable configurations | Confirm the precise target landscape, product version and current certification scope |
| SAP S/4HANA Cloud Public Edition | Not supported under current published requirements | The existing SAP-side installation model is not supported in this edition |
What does “S/4HANA compatible” actually mean?
Process Runner GLSU—previously known as ZOption GLSU and now offered by insightsoftware—is an Excel-based tool used to prepare, validate and post financial transactions to SAP. For organisations researching ZOption GLSU and S/4HANA, the underlying operating model remains important: the product uses an Excel add-in together with SAP-side components installed by transport.
Compatibility should be assessed at two levels.
The first is product support: does the installed GLSU version support the organisation’s target S/4HANA release and deployment edition?
The second is architectural fit: can the required transports, authorisations, desktop components and connection methods operate within the organisation’s target SAP landscape and governance model?
A product can be technically supported on S/4HANA while still requiring infrastructure or user access that an organisation intends to reduce after migration. This is why “supported” and “strategically aligned” are not necessarily the same conclusion.
What changes when GLSU moves from SAP ECC to S/4HANA?
For existing GLSU users, moving from ECC to S/4HANA does not automatically require the journal process to be rebuilt. However, a GLSU ECC vs S/4HANA assessment should account for the changes to the underlying finance environment, even where the familiar Excel preparation model and SAP-side installation continue in supported environments.
However, an S/4HANA migration changes the underlying finance environment. The Universal Journal places ACDOCA at the centre of financial and controlling line-item data, while some ECC tables and behaviours are changed, replaced or made available through compatibility mechanisms.
Organisations should therefore revalidate the complete journal-posting path, including:
- the installed GLSU and SAP/ABAP component versions;
- journal templates and field mappings;
- SAP authorisations and segregation of duties;
- custom Z-programs, enhancements and validation logic;
- authentication and connectivity;
- document posting, error handling and drill-back; and
- regression testing against the target S/4HANA finance configuration.
The current GLSU system requirements state that existing customers moving to S/4HANA 1909 or later require a minimum installation of GLSU 6.2c SAP/ABAP components. This GLSU SAP HANA version support requirement should be included in migration design and testing rather than treated as a post-go-live configuration task.
SAP GUI, Fiori and the end-user operating model
GLSU’s current requirements include supported versions of Microsoft Excel and SAP GUI on the user’s Windows environment. GLSU can also use RFC connectivity for direct Excel-to-SAP posting, so it would be inaccurate to describe the solution as relying exclusively on SAP GUI scripting.
Moving to S/4HANA does not itself remove SAP GUI. Many organisations continue to use classic SAP transactions alongside Fiori applications. The issue is instead whether the SAP GUI dependency for GLSU fits the organisation’s intended long-term access model.
This becomes relevant where an organisation plans to :
- move finance users towards Fiori-led or browser-based access;
- reduce local desktop dependencies;
- manage virtual-desktop or endpoint software more tightly; or
- limit SAP GUI access for particular user populations.
GLSU provides some Fiori interoperability, including the ability to expose the ZGLSU transaction as a Fiori tile. However, insightsoftware’s documentation states that document drill-back does not work for customers using only SAP Fiori, and that some troubleshooting activities require SAP GUI access.
The practical question is therefore not “Does Fiori immediately break GLSU?” It does not. Organisations assessing a GLSU SAP Fiori alternative should instead consider whether maintaining the necessary SAP GUI and Windows desktop components remains consistent with their target user experience and endpoint strategy.
Transports, clean core and RISE with SAP
SAP S/4HANA Cloud Private Edition allows customers greater flexibility than the public-cloud edition, including the use of qualifying third-party solutions and extensions. GLSU on S/4HANA private cloud can therefore operate in supported configurations where the relevant product and landscape requirements are met.
Clean core should not be interpreted as meaning that every extension must run on SAP BTP or that every on-stack extension is prohibited. SAP recognises both on-stack and side-by-side extensibility. The relevant governance question is whether an extension uses approved mechanisms, remains maintainable and can be managed through future upgrades.
GLSU is installed through an SAP transport and is not a BTP side-by-side extension. GLSU SAP BTP compatibility should therefore not be interpreted as GLSU operating as a BTP-native application. An organisation adopting clean-core principles should consequently determine :
- which GLSU objects are installed in the SAP environment;
- how those objects are classified under its extension policy;
- how they will be tested and maintained during upgrades; and
- whether the approach remains acceptable under its RISE operating model.
Licensing considerations during migration
GLSU is available as a standalone product. Published documentation also distinguishes between Standard and Premium users, with different capabilities and support rights.
GLSU documentation states that the licence must be unlocked for each SAP system and client in which it is used. Publicly available documentation does not establish that every existing ECC commercial entitlement will transfer unchanged to a new S/4HANA or private-cloud landscape. GLSU licensing for S/4HANA should therefore be confirmed as part of the migration planning process.
Customers should confirm directly with insightsoftware :
- required Standard and Premium user numbers;
- development, test, quality and production-system entitlements;
- SAP client licensing requirements;
- rights to move from ECC to S/4HANA; and
- any contractual effect of moving to SAP S/4HANA Cloud Private Edition.
Comparing GLSU with Promenta’s journal-management architecture
For organisations reviewing journal tools as part of an S/4HANA migration, the decision should extend beyond basic compatibility and consider any GLSU limitations in S/4HANA that are relevant to the intended operating model.
Promenta has worked with SAP customers for more than 20 years. Its journal-management solution runs within the customer’s SAP ECC or SAP S/4HANA environment, including supported on-premise and SAP S/4HANA Cloud Private Edition deployments.
Promenta’s workflow interface is web-based and served from the customer’s SAP environment. Core journal preparation, submission and approval do not require end users to operate through SAP GUI. SAP users, authorisations, workflow rules and audit records remain within the customer’s SAP environment, without a separate application server or external workflow platform in the journal-posting path.
Finance users can continue preparing journal data in Excel through the Promenta Excel add-in (which is also compatible with the GLSU excel sheet format), while applying live validation against SAP master data and SAP-configured financial controls, including applicable GGB0 validation rules.
The Promenta operating model provides :
- browser-based preparation, submission and approval workflows;
- live validation against current SAP data and configured finance controls;
- validation and posting simulation before a journal is submitted;
- configurable approval routing and segregation-of-duties controls;
- supporting documentation retained with the journal process;
- a connected audit trail from preparation through approval and posting; and
- no separate external application server or middleware in the journal-posting path.
The distinction is not that GLSU cannot run on S/4HANA. It is that the two products address journal processing through different end-user and control architectures.
| Evaluation area | GLSU | Promenta |
|---|---|---|
| Excel preparation | Yes | Yes |
| SAP-side components | Installed by transport | Installed within the customer’s SAP environment |
| Core end-user workflow | Excel and external Microsoft server operating model | Web-based workflow served from SAP |
| SAP GUI | Required within the supported client environment; some functions specifically depend on it | Not required for core journal preparation and approval |
| Validation | SAP-connected validation and posting capabilities | Live SAP validation, configured finance controls and pre-submission posting simulation |
| Approval and control | Depends on selected GLSU/Process Runner capabilities and configuration | Integrated multi-stage workflow, approval routing, supporting evidence and audit trail |
| External workflow infrastructure | Confirm for the selected configuration | No separate application server or middleware in the journal-posting path |
Organisations should validate both vendors’ current capabilities against their precise requirements and versions before relying on this summary.
Six checks before relying on GLSU after migration
For organisations asking “Will GLSU work after S/4HANA migration?”, these six checks help establish whether both the product support and operating model remain appropriate.
- Confirm the deployment edition and release. Check that the intended on-premise or private-cloud landscape appears in current GLSU support documentation.
- Confirm the GLSU and SAP component versions. Include any required SAP/ABAP transport upgrade in the migration plan.
- Review transport and clean-core governance. Determine whether the installed objects comply with the organisation’s extension and upgrade policies.
- Confirm desktop and connectivity requirements. Validate supported SAP GUI, Excel, Windows, RFC, scripting and authentication requirements against the target environment.
- Confirm licensing and migration rights. Review user categories, systems, clients and contractual entitlements with insightsoftware.
- Retest the complete journal process. Test templates, mappings, authorisations, custom logic, validations, approvals, posting and drill-back against the target S/4HANA finance configuration.
These checks are most valuable during migration design. An incompatibility found during testing can usually be addressed within the programme; the same problem discovered during period close becomes an operational risk.
Conclusion
GLSU and SAP S/4HANA are compatible in qualifying on-premise and private-cloud environments. Its documented requirements nevertheless make the target edition, GLSU version, SAP-side components, desktop environment and licensing important parts of migration planning.
For organisations retaining Excel-led processing, SAP GUI and the existing GLSU architecture, continued use may be entirely workable. For organisations using S/4HANA migration to introduce browser-based workflows, stronger SAP embedded controls and fewer desktop dependencies, compatibility alone is not the deciding standard.
Compatibility answers whether a solution can run. Architecture, control and user experience help determine whether it remains the right fit.
Frequently Asked Questions
Does GLSU work with SAP S/4HANA?
Yes, in qualifying environments. Whether GLSU will work after an S/4HANA migration depends on the target S/4HANA edition, GLSU version, SAP/ABAP components and system configuration. Existing customers moving to S/4HANA 1909 or later should also account for the minimum GLSU component requirements during migration planning and testing.
Does GLSU require SAP GUI?
GLSU’s current system requirements include a supported SAP GUI installation. It can use RFC for direct posting, so not every interaction relies on GUI scripting. However, particular features and troubleshooting activities require SAP GUI, and insightsoftware states that document drill-back is unavailable in a Fiori-only environment. Organisations should therefore consider the SAP GUI dependency for GLSU when planning a browser-led access model.
What is the difference between a native SAP journal workflow and a non-native workflow?
GLSU RISE with SAP support applies to applicable SAP S/4HANA Cloud Private Edition configurations. Customers should verify their precise RISE landscape, GLSU version and current support or certification position directly with insightsoftware.
What is the difference between SAP journal entry upload and journal entry verification?
Public documentation does not establish that every ECC entitlement transfers unchanged. As part of GLSU licensing for S/4HANA, customers should confirm their user, system, client and migration rights directly with insightsoftware before moving.
Can finance teams prepare SAP journals in Excel and still use an approval workflow?
Testing should cover the GLSU and SAP component versions, journal templates, field mappings, authorisations, authentication, connectivity, custom logic, validation, posting, error handling and drill-back against the target S/4HANA finance environment.