GLSU S/4HANA Issues: What Finance Teams Discover After Go-Live

Summarize and analyze this article with

Many finance teams use GLSU for journal uploads in SAP and assume the same process will carry into S/4HANA. During migration, attention naturally goes to the ledger, finance configuration, integrations, and reporting. The journal upload process can appear to be one of the components that simply moves with them.

So, is GLSU compatible with SAP S/4HANA? Yes, in supported environments, although the answer depends on the deployment model, S/4HANA release and GLSU version in use, as covered in our GLSU and SAP S/4HANA compatibility guide.

However, compatibility does not mean the operating model remains unchanged, and that is where most GLSU S/4HANA issues start. S/4HANA can expose dependencies around desktop software, SAP GUI availability, authentication, validation, workflow, and audit evidence that were easier to accommodate in ECC. Those differences often become clearer after go-live, when finance runs its first close at full volume.

This article looks at where GLSU continues to work, what changes under S/4HANA, and what teams should assess when the existing process starts to show its limits.

Key Takeaways

GLSU runs on S/4HANA On-Premise 1709 or later and on most Private Cloud setups. It is not supported on Public Cloud.
Most issues show up after go-live, not as one compatibility failure.
The 5 common issues are: access and login, validation, feature differences (such as Fiori drill-back), approval outside the upload, and version-specific support.
The first live month-end close is usually where these issues surface.

Does GLSU Still Work After S/4HANA Go-Live?

Yes, provided the target environment meets the vendor’s published requirements. Process Runner GLSU is insightsoftware’s Excel-based tool for preparing, validating and posting journal entries to SAP. Its vendor currently lists support for S/4HANA On-Premise from release 1709 onwards. It also states that SAP Private Cloud is supported in most cases, while SAP S/4HANA Cloud Public Edition is not supported. Existing customers moving to S/4HANA 1909 or later require at least GLSU 6.2c SAP/ABAP components.

That creates three practical scenarios:

S/4HANA On-Premise : GLSU can continue to operate where the required GLSU version, SAP components, and desktop environment are maintained.
S/4HANA Cloud Private Edition / RISE : support is possible, but the precise landscape, GLSU version, and technical requirements should be confirmed for the target environment.
S/4HANA Cloud Public Edition : current GLSU system requirements state that it is not supported.

For finance teams, the useful question after establishing compatibility is whether the existing GLSU operating model still fits the organisation’s S/4HANA architecture, access strategy, and journal-control requirements.

See how Promenta keeps journal preparation, validation, approval and audit evidence inside SAP.

Does GLSU Need SAP GUI After Moving to S/4HANA?

Process Runner GLSU combines an Excel add-in with SAP-side components. Its current desktop requirements include Windows, desktop Microsoft Excel, and a supported SAP GUI version. The product also requires GLSU components to be installed in the SAP system through transport.

SAP GUI is part of the supported GLSU client environment, although GLSU does not rely exclusively on SAP GUI scripting for every function.

In ECC, this dependency may attract little attention. SAP GUI is already part of the standard desktop environment for many finance teams, so maintaining another Excel-based process around it does not necessarily change how users work.

S/4HANA can alter that assumption. Some organisations use the migration to move finance users towards Fiori-led or browser-based access, reduce locally installed desktop components, or tighten how SAP GUI is provisioned. When that happens, GLSU’s client requirements become an architecture decision rather than a background technical detail.

GLSU does provide some Fiori interoperability, including the ability to expose its ZGLSU transaction through a Fiori tile. However, insightsoftware documents GLSU limitations in Fiori-only environments, so teams should test the specific GLSU capabilities they rely on before adopting a Fiori-only access model.

For SAP S/4HANA Cloud Public Edition, the support position is clear: insightsoftware’s current system requirements state that GLSU is not supported.

5 GLSU S/4HANA Issues Finance Teams Discover After Go-Live

Where GLSU remains supported, the migration does not normally result in one obvious compatibility failure after S/4HANA go-live. Teams are more likely to encounter individual issues as the new environment is used under live conditions.

1. Login and access issues after cutover

Authentication, SAP authorisations, desktop configuration and connectivity can all change during an S/4HANA programme. Because GLSU spans Excel, the desktop client, and SAP-side components, those changes need to be tested together.

A login or connection problem after cutover may therefore reflect the new access model rather than an inherent failure of GLSU itself, so start with the common reasons GLSU is not working in SAP.

2. Validation must be retested against S/4HANA

GLSU does provide pre-posting validation. Users can validate spreadsheets before posting, and Premium configurations can use live SAP master data for selected validations. Errors found during GLSU validation can be returned to the spreadsheet for correction.

The migration issue is different: GLSU validation in S/4HANA needs to be retested against the target finance configuration. Changes to master data, field requirements, authorisations, custom validation logic, or posting configuration can produce behaviour that was not present in ECC.

Finance teams should therefore test not only whether a journal uploads to S/4HANA, but whether the complete validation and posting path catches the right errors before they reach the final posting step.

3. Features can change even when the upload works

A successful journal post does not prove that every surrounding feature works exactly as it did before migration. Templates, field mappings, authentication, custom logic, drill-back, and troubleshooting behaviour should all be regression-tested against the target S/4HANA environment.

Fiori is a useful example. GLSU can expose its SAP transaction through a Fiori tile, but insightsoftware specifically notes that document drill-back is unavailable where the customer has only SAP Fiori.

This is why post-migration assessment needs to look at the whole user process rather than treating a successful upload as the only compatibility test.

4. Approval may still sit outside the GLSU upload

GLSU provides controls around journal preparation, validation and posting, but a controlled GLSU approval workflow is a separate consideration. For organisations that require an approval process around the spreadsheet, insightsoftware documents integration between GLSU and its EWF (Easy Workflow) product.

Finance teams should map where journal preparation, review, approval, supporting evidence and posting are recorded, then assess whether the complete history can be retrieved as a single, reportable audit trail.

If approvals still depend on email, shared folders, or another disconnected process, auditors may still require teams to reconstruct the approval history manually. The migration is an opportunity to close that evidence gap with a journal entry approval workflow in S/4HANA rather than reproduce it in the new environment.

5. Support depends on version and deployment model

Support is not a blanket yes or no. As covered in the first section, it depends on the exact S/4HANA release, deployment model and installed GLSU version, so check it against your environment rather than assuming it from the product name alone.

GLSU S/4HANA issues at a glance

Issue	Typical symptom	When it shows up	What to check
1. Login and access	Login or connection problems after cutover	Soon after cutover	Authentication, SAP authorisations, desktop configuration and connectivity, tested together
2. Validation	Errors that were caught in ECC reach the posting step	Migration testing or the first live close	Master data, field requirements, custom validation logic and posting configuration
3. Feature differences	The upload works, but features such as drill-back behave differently	After migration, especially with Fiori-only access	Templates, field mappings, custom logic, drill-back and troubleshooting
4. Approval outside the upload	Approval evidence spread across SAP, email and shared folders	During journal review or audit	Whether preparation, review, approval and posting form one reportable audit trail
5. Version-specific support	Assumed support does not match the actual landscape	During migration planning	S/4HANA release, deployment model, GLSU version and SAP/ABAP component level

When Do GLSU Issues Show Up After S/4HANA Go-Live?

Some issues are caught during migration testing. Others only become visible when the first live close puts the new environment under realistic pressure.

A test journal proves that a posting path works. Month-end tests much more: journal volume, multiple preparers, approval dependencies, authorisation changes, error handling, supporting documentation and a fixed reporting deadline.

That is why the first month-end close with GLSU on S/4HANA, or the first period close, is often the point at which smaller process gaps become operational problems. A validation or access issue that affects one test journal is inconvenient. The same issue across dozens or hundreds of journals inside the close window can delay reporting.

Audit gaps may surface later, when finance is asked to reconstruct who prepared, reviewed, and approved a particular journal and what evidence supported the decision.

The useful post-go-live measure is therefore not simply whether GLSU survived cutover. It is whether the journal process survives the first close with its controls, evidence and turnaround time intact.

GLSU vs an SAP-Native Approach to Journal Management in S/4HANA

GLSU and a native SAP journal-management model organise the process differently.

Area	GLSU	SAP-native journal-management model
Preparation	Excel is the primary preparation environment, through an installed add-in and SAP-side components	Excel can remain part of the process, with the control path kept within the SAP environment
Validation	Users validate journal data, then post or park it in SAP	Validation runs against the same SAP users, master data, authorisations and finance rules
Approval	A separate consideration, for example through the Easy Workflow integration	Workflow and approval operate within the SAP environment
Audit evidence	Can be spread across SAP, email and shared folders	Audit reporting operates against the same SAP environment
Desktop dependency	Windows, desktop Excel and SAP GUI remain part of the operating architecture	Can reduce reliance on SAP GUI for core journal processing

Promenta follows an SAP-native architecture. Its SAP Journal Entry Management solution runs within the customer’s SAP environment and supports journal preparation through its web interface or SAP-integrated Excel Add-in. Journals can be validated against SAP data, posting-simulated before submission, routed through configurable approval workflows, and retained with a connected audit record.

This architecture is particularly relevant where an S/4HANA programme, including journal entry management in S/4HANA Private Cloud, is reducing reliance on SAP GUI for core journal processing, strengthening approval controls or keeping journal evidence within the SAP security and governance boundary.

Excel can remain part of either approach. Validation, approval, posting controls and audit evidence differ in where and how they are maintained.

SAP ECC mainstream support ends 2027. See how Promenta keeps journal control inside SAP through the transition.

How to Fix GLSU S/4HANA Issues: A 6-Step Remediation Plan

If GLSU remains operational after migration but the surrounding process no longer meets the organisation’s requirements, start with the gaps rather than immediately replacing the tool. The six steps below apply to any GLSU S/4HANA migration.

1. Confirm the deployment model and support position

Document the target S/4HANA edition, release, installed GLSU version, and SAP/ABAP component level. For Private Cloud or RISE environments, confirm the specific configuration against the vendor’s current requirements.

2. Confirm the long-term desktop access model

Establish whether finance users will continue to receive supported Windows, desktop Excel, and SAP GUI environments. If the organisation is deliberately moving towards browser-led or Fiori-only access, identify which GLSU functions would be affected.

3. Map validation and approval separately

Document what GLSU validates before posting, what remains dependent on SAP posting checks, and where review and approval happen. This avoids treating “validation” and “approval” as the same control.

4. Measure exposure during close

Look at journal volumes, peak submission periods, recurring posting errors, approval turnaround, and the amount of manual intervention required, which is where the risk of manual journal entries in SAP builds up. These measures show whether an isolated technical limitation is actually material to the close.

5. Test the audit trail

Select a posted journal and attempt to reconstruct its complete history: preparation, validation, supporting documentation, review, approval, amendments and final posting. Any evidence that has to be assembled manually is a control gap worth addressing.

6. Evaluate a native SAP alternative where the gaps justify it

For teams that need validation, approval and audit evidence to operate as one connected SAP-based process, assess whether an SAP-native journal-management model better fits the target S/4HANA architecture, starting with a side-by-side Promenta vs GLSU comparison.

Where Promenta is selected, the fastest GLSU-to-Promenta migration achieved to date has been four weeks from project sign-off to go-live. That should be treated as the fastest achieved implementation, not as a standard or guaranteed migration duration.

Promenta's SAP Journal Entry Management solution provides Excel-based preparation, live SAP validation, configurable approval, posting, and audit evidence within the SAP journal process.

Conclusion

GLSU is compatible with SAP S/4HANA in defined environments. Current vendor documentation supports S/4HANA On-Premise from 1709 and Private Cloud in most cases, subject to the relevant product and system requirements. SAP S/4HANA Cloud Public Edition is currently not supported.

For teams already running GLSU, that answers the technical compatibility question. It does not answer whether the existing journal process remains the right fit after migration.

The stronger post-go-live test is whether the process still provides reliable access, appropriate validation, controlled approval, and retrievable audit evidence during a live close.

An SAP-native journal-management model can connect those stages into one controlled path:

Prepare → Validate → Submit → Route → Review → Approve → Post → Audit

Before deciding whether the current process should remain in place, ask:

Does the target S/4HANA environment continue to support the GLSU version and desktop components we depend on?
Is SAP GUI access part of the long-term finance-user strategy?
Which journal errors are identified before submission, and which can still emerge later in the posting process?
Can we produce a controlled, reportable history of preparation, review, approval, and posting for an individual journal without reconstructing evidence manually?

If those questions expose gaps, Promenta’s SAP Journal Entry Management solution provides an alternative that keeps Excel-based preparation while bringing SAP-connected validation, approval workflow, posting and audit reporting into the SAP environment.

Frequently Asked Questions

1. What happens to GLSU functionality when an organisation migrates to S/4HANA?

GLSU can continue operating after an S/4HANA migration where the target environment meets its requirements. Teams should retest authentication, authorisations, templates, validation, custom logic and posting behaviour because the surrounding SAP environment may have changed even when the core upload continues to work.

2. Can GLSU run in a Fiori-only S/4HANA environment?

Not fully. GLSU’s published desktop requirements include a currently supported SAP GUI version, together with Windows and desktop Microsoft Excel. Some GLSU functionality can also operate through Fiori integration, but insightsoftware documents limitations in Fiori-only environments, including unavailable document drill-back and SAP GUI requirements for some troubleshooting scenarios.

SAP GUI remains available in many S/4HANA On-Premise and Private Edition environments, so teams should confirm whether it remains part of their long-term finance-user access model.

3. What specific GLSU features can be affected after moving to S/4HANA?

Features that depend on the surrounding S/4HANA environment may need to be retested, including authentication, authorisations, field mappings, custom logic and Fiori-related functions. One documented limitation is that GLSU document drill-back is unavailable in a Fiori-only environment. The exact impact depends on the GLSU version, S/4HANA release, and deployment configuration.

4. How quickly do GLSU S/4HANA issues appear after go-live?

Technical incompatibilities may appear during migration testing, but process weaknesses often become clearer during the first live month-end or period close. Higher journal volumes, multiple users, approval dependencies, and reporting deadlines expose issues that a small number of test postings may not reveal.

5. What is the recommended remediation plan when GLSU falls short in S/4HANA?

Confirm the deployment and GLSU support position first. Then review the desktop access model, validation coverage, approval process, journal volumes, and audit evidence. If the gap is architectural rather than a configuration issue, evaluate whether a native SAP journal-management solution can consolidate validation, workflow, approval, and audit reporting within the SAP environment.