Contact Us

Tag: Promenta

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

Posted on by by promenta
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.
Book a 30-Min Demo

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.
Book a 30-Min Demo

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.
Talk to an SAP Specialist

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

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.

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.

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.

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.

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.

Journal Entry Approval Workflow in SAP S/4HANA: How It Works, How to Set It Up, and Where It Falls Short

Posted on by by promenta

The journal entry approval workflow in SAP S/4HANA is managed through General Journal Entry Verification, a native SAP Fiori capability that routes general ledger entries to designated approvers before posting. Finance users submit the journal; the system evaluates configured conditions and assigns a processor; the approver reviews and either approves or rejects the entry. Once all required verification steps are complete, the journal progresses to posting.

Approving journal entries before they post is a vital financial control.

A journal entry approval workflow in SAP S/4HANA ensures that selected entries are reviewed and authorised before they are posted – using a native mechanism called General Journal Entry Verification, which allows journal entries to be submitted for review and routed to the appropriate approver.

For finance teams, however, approval is only one part of the journal process.

The wider control question is whether the journal has been prepared correctly, validated against SAP standards, supported with the required evidence, routed according to the organisation’s policy and retained with an end-to-end audit trail.

This article explains how the journal entry approval workflow in SAP S/4HANA operates, how the standard verification process is configured and where organisations may need additional journal management controls.

While this article focuses on SAP S/4HANA, the same approval principles and limitations apply to SAP ECC environments, where Promenta also operates natively.

What Is the Journal Entry Approval Workflow in SAP S/4HANA?

SAP S/4HANA uses General Journal Entry Verification – its native general ledger approval mechanism – to manage which journal entries require review before posting.

A finance user creates the journal and submits it for verification. An active workflow evaluates the conditions defined by the organisation and determines whether verification is required and who should receive the journal.

The designated person can then review the accounting information and take the appropriate action.

Where multiple verification steps are required, the journal progresses through the configured sequence before it can complete the process.

This is crucial, because the journal entry approval workflow in SAP S/4HANA is not simply the act of passing a journal from one person to another.

Its value as a financial control comes from ensuring that the required review takes place against a planned approval process, before the journal is allowed to progress through to posting.

It is also useful to distinguish journal upload from journal verification.

SAP provides standard functionality for uploading general journal entries from spreadsheet files. General Journal Entry Verification is the workflow capability used to control review and approval.

Though these are related activities, they are not the same process.

In SAP S/4HANA, General Journal Entry Verification is supported by three Fiori apps: the Verify General Journal Entries app for requesters (F2547), and two processor apps – the Inbox (F2728) and Outbox (F2729). The process is driven by standard Workflow Scenario WS02800046, which organisations configure and extend through the Manage Workflows for General Journal Entry Verification Fiori app.

SAP ECC mainstream support ends 2027. See how Promenta keeps journal control inside SAP through the transition.
Book a 30-Min Demo

Journal Entry Approval Workflow in SAP S/4HANA: Step by Step

The exact applications and options available can vary depending on the S/4HANA deployment and release, but the standard approval process broadly follows these stages.

1. Create the journal entry

Step 1: Create the Journal Entry. The requester prepares the journal, including relevant accounts, amounts, company code, and any required supporting information.

The journal contains the accounting information required for posting, including the relevant accounts, amounts, company code and other financial dimensions.

Supporting information may also need to be provided depending on the organisation’s control requirements.

2. Submit the journal for verification

Step 2: Submit for Verification. Once the entry is ready, the requester submits it into the verification process, creating a formal control point before approval or posting.

This creates a formal control point between journal preparation and the subsequent approval or posting activity.

The journal’s status also becomes visible within the workflow rather than relying on separate emails or manual follow-up.

3. SAP determines the approval route

Step 3: SAP Determines the Approval Route. The active workflow evaluates configured conditions and determines which verification process and approver should apply

Approval routing can reflect criteria relevant to the organisation’s financial-control model, such as:

  • Company code
  • Journal value
  • Journal entry type
  • Accounting characteristics
  • Organisational responsibility

So, different journals can follow different approval paths.

A routine lower-value entry may require a relatively simple process or no approval, while a higher-value or higher-risk journal usually requires additional verification.

4. The approver reviews the journal

Step 4: The Approver Reviews the Journal. The designated approver reviews the journal and the available information to make an informed decision.

The approver needs sufficient information to determine whether the journal is appropriate and the required financial controls have been followed.

Depending on the configured process, the approver may approve, reject, or suspend the journal.

5. The journal progresses towards posting

Step 5: The Journal Progresses Towards Posting. Once all required verification steps are complete, the journal continues through the configured process towards posting.

This connects approval to the journal lifecycle.

Where additional approval levels have been configured, each required step must be completed according to the workflow design.

6. Workflow status remains traceable

Step 6: Workflow Status Remains Traceable. The workflow provides full visibility into the journal’s progress status and the actions taken during verification.

Requesters and finance teams can see whether an entry is awaiting action, approved or rejected. They do not need to maintain a separate approval tracker.

This creates the basic SAP journal approval path:

Workflow-status-remains-traceable

The next consideration is how that routing is configured around the organisation’s own policies.

How to Configure Journal Entry Approval in SAP S/4HANA: General Journal Entry Verification

SAP journal entry workflow configuration for General Journal Entry Verification is managed through standard SAP workflow-management functionality.

At a high level, organisations define:

  • When verification should apply : Preconditions determine which journal entries enter a particular workflow.
  • The sequence of verification steps : The workflow defines whether one or multiple review stages are required.
  • Who should verify the journal : Responsibility can be determined according to the organisation’s defined approval structure.
  • How exceptions should be handled : Workflow behaviour can reflect different outcomes and processing requirements.
  • Which workflow is active : The required workflow must be configured and activated for the relevant scenario.

Thus, while SAP provides the framework for journal verification, the organisation still needs to translate its financial-control requirements into that framework i.e. design and build the workflow.

Approval thresholds, responsibilities, organisational structures and exceptions all need to reflect the way the finance function operates.

That becomes particularly relevant as entities, approval responsibilities or control policies change.

What Are the Limitations of SAP S/4HANA Journal Entry Approval?

General Journal Entry Verification provides an important approval control.

But approval is not the complete journal lifecycle.

Finance teams must also consider what happens before the approval starts and what evidence remains after the journal posts.

Excel preparation and SAP upload remain separate considerations

Excel remains widely used for journal preparation because it is practical for calculations, analysis, and complex financial data – a dynamic explored further in our guide to automated vs manual journal entries.

However, the manual entry process is not the biggest challenge here; it is how the spreadsheet connects to SAP.

SAP’s standard functionality for uploading general journal entriesallows journal information to be transferred from a spreadsheet into S/4HANA. This can remove some direct screen entry, but a file-based upload is different from having SAP functionality available inside Excel during preparation.

A deeper Excel-to-SAP process can provide controls while the journal is still being prepared, including:

  • SAP-connected picklists
  • Validation master-data
  • SAP finance validation
  • Duplicate prevention
  • Controlled submission into workflow
  • Status visibility

The distinction is not simply whether SAP can receive an Excel file.

It is the degree of SAP control available before that file reaches the posting stage.

Approval does not replace early validation

Approval establishes whether the journal has been authorised.

Validation establishes whether the journal data itself is acceptable for posting.

A journal can be properly approved and still contain an account, cost object, period or other value that causes a posting problem later.

Therefore, the timing of validation matters.

If a material SAP error is discovered only after a journal has completed several approval stages, the entry may need to be corrected, resubmitted and approved again.

This creates unnecessary work during the close period, when finance teams are already under time pressure.

A better journal entry process offers more control and moves validation closer to preparation.

See Promenta's SAP Journal Workflow in Action

Built natively on SAP. No external servers, no duplicate financial data.

Request a Personalised Demonstration

The aim is to identify avoidable posting problems before approvers spend time reviewing the journal.

Approval and validation serve different purposes.

A controlled process needs both.

Workflow administration can become a practical issue

Approval requirements rarely remain static.

People change roles. Organisations restructure. Approval thresholds are revised. Substitute approvers are needed during leave or close periods.

SAP provides configurable workflow capabilities, but organisations still need to consider how teams can easily maintain day-to-day approval structure.

If every routine change requires technical intervention, workflow administration can become another source of delay.

Finance teams therefore need to assess not only whether a workflow can be configured, but also how easily authorised users can maintain approval teams, thresholds, hierarchies and substitutes as operating requirements change.

High-volume journals need additional handling

Control requirements do not disappear when journal volumes increase.

Month-end and year-end can involve large journals, multiple requests and significant volumes of accounting adjustments moving through a limited close window.

Relevant standard SAP journal upload and verification scenarios can also encounter line-item constraints around large journal documents.

For finance teams processing entries beyond those limits, the process may need to divide the journal into multiple balanced SAP documents while maintaining the required validation and approval controls.

The same issue applies when several journals are prepared together.

Efficiency at close depends on being able to process volume without creating a separate manual control process for each journal.

Approval evidence needs to form part of the wider audit trail

Recording an approval action is useful.

However, for audit purposes, organisations may need to demonstrate substantially more than the final approval – a challenge explored in detail in our guide to SAP journal entry compliance.

That can include :

  • Who prepared the journal
  • What information supported it
  • What validation occurred
  • When it was submitted
  • Who reviewed and approved it
  • Whether it was rejected or amended
  • What supporting documentation was attached
  • When it was posted
  • Whether it was subsequently reversed

Thus, finance teams should also oversee whether the complete journal lifecycle can be reconstructed and reported from a connected control record.

How to Extend SAP Journal Entry Approval Beyond the Native Workflow

For organisations that require more than journal verification alone, Promenta brings Excel preparation, SAP validation, approval, posting and audit evidence into one controlled journal process.

It operates natively within S/4HANA (and ECC) instead of introducing a separate external platform into the core journal path.

SAP-integrated Excel preparation

Finance teams can continue working in Excel using the Promenta Excel Add-In , which connects directly to SAP during journal preparation.

Instead of preparing a disconnected spreadsheet and uploading it at the end, users can access SAP-connected functionality while the journal is being created.

This includes capabilities such as dynamic SAP picklists, add or remove journal fields, validation of all journal data prior to posting, as well as direct workflow submission from Excel ensuring strong compliance control.

Promenta also provides a Template Manager which supports multiple Excel journal templates e.g. GL, AP, AR, Recurring, Intercompany etc.

Even if Excel remains the preparation environment, the controls around it improve and journal risk is diminished.

Validation before approval

Promenta creates a fully validated virtual journal document and runs a full simulated SAP posting at the request stage.

This means the journal is tested against the SAP environment before it moves through approval.

Errors can be returned to the requester while the entry is still being prepared rather than after a multi-stage approval process.

That changes where rework occurs.

An issue corrected before submission creates far less disruption than the same issue discovered immediately before posting.

This capability is possible because Promenta runs natively inside S/4HANA, the system of record, unlike alternative external or cloud based solutions.

Journal-specific configurable workflow

Promenta provides an enterprise journal workflow designed specifically around  documented financial approval rules and compliance requirements.

Routing can reflect any combination of fields available in the journal e.g. governed by company code, value, GL etc. and incorporates:

  • Multiple approval levels
  • Approval hierarchies
  • Approval teams
  • Substitute approvers
  • Segregation of duties
  • Self-approval prevention
  • Rejection and resubmission
  • Mandatory supporting information

The workflow is highly configurable without requiring every routine business change to become a coding exercise.

This allows the approval model to remain aligned with the organization as responsibilities and control requirements change.

Controlled posting and connected audit evidence

A journal does not progress simply because its spreadsheet has been uploaded.

Validation, approval and other required controls form part of the path towards posting.

The resulting journal history retains the preparation, supporting documentation, validation, approvals, rejections, amendments and posting activity as part of a reportable audit record.

This makes audit evidence a product of the process — finance teams do not need to reconstruct it after the close.

SAP-native architecture

Where the workflow operates is also a governance consideration.

Promenta runs within S/4HANA and SAP ECC, allowing the journal process to remain aligned with the organisation’s SAP users, authorisations, master data, finance configuration and security environment.

Sensitive journal information need not be moved to a separate external platform for the core workflow.

For organisations running SAP ECC as well as S/4HANA, the same journal entry approval principles and process limitations apply – Promenta’s solution addresses both environments natively.

This reduces the additional infrastructure, integrations and governance boundaries associated with managing the process across multiple non-SAP systems and environments.

Promenta has partnered with SAP for over 20 years and has been an SAP-certified partner since 2004, developing its Journal Management capabilities specifically for SAP finance environments.

SAP S/4HANA Native Journal Approval vs Promenta Journal Management: Feature Comparison

The table below shows how standard SAP S/4HANA journal approval compares with Promenta Journal Management across the wider journal process.

Area Standard SAP S/4HANA Promenta Journal Management
Journal upload Standard spreadsheet-based upload capability SAP-integrated Excel Add-In capable of deep SAP finance validation in the Excel context, add/remove journal fields, template manager, park, post, send-to-workflow
Excel preparation Spreadsheet prepared for subsequent upload Excel connected directly to SAP functionality during preparation
Templates Standard upload structure Template Manager supporting multiple journal templates
SAP validation from Excel File-based upload process Real-time SAP integration, deep transactional validation and dynamic picklists
Approval General Journal Entry Verification configured for organisational requirements Pre-built and proven journal-specific configurable workflow software
Pre-approval validation Depends on the standard process and configuration used Fully validated virtual journal with simulated posting before approval
Segregation of duties Depends on workflow and SAP authorisation configuration Journal-specific SoD controls and self-approval prevention
Workflow administration Configured within the standard SAP workflow framework Highly configurable journal workflow with no-code administration
High-volume processing Standard upload and document constraints apply Supports larger and multiple journals through the controlled process
Audit evidence SAP journal and workflow records Continuous, reportable preparation-to-posting journal audit trail and external support documentation storage against the SAP finance document

The standard SAP process may be suitable for organisations requiring a relatively straightforward journal verification model.

A broader journal management solution becomes more relevant when finance teams also need deeper Excel integration, earlier SAP validation, flexible journal-specific routing, high-volume processing and connected audit reporting.

Conclusion

For organisations evaluating a journal entry approval workflow in SAP S/4HANA, the native General Journal Entry Verification mechanism provides an important starting point.

As the journal volumes, entities and approval requirements increase in complexity, finance teams need to consider whether enhanced SAP partner tooling like Promenta is more appropriate to meet their process needs.

The process also needs to address how journals are prepared, when they are validated, how segregation of duties is enforced, how easily approval structures can adapt, and whether supporting evidence remains connected throughout the journal lifecycle.

Promenta extends the process beyond simple upload by connecting Excel preparation, live SAP validation, simulated posting, configurable workflow, controlled posting and audit evidence within SAP.

The result is a journal process designed to identify issues earlier, enforce the required controls before posting and maintain an end-to-end audit trail, supporting SAP finance teams to mitigate journal risk and pass audits.

If those questions are difficult to answer, the issue may lie less with journal preparation itself and more with the process surrounding it.
Explore Promenta's SAP Journal Entry Workflow solution

Frequently Asked Questions

In SAP S/4HANA, a journal entry that requires verification is created and submitted into the General Journal Entry Verification process.

The configured workflow determines which approver or processor should receive the entry. The approver reviews the journal and can take the appropriate action, such as approving or rejecting it.

Once all required verification steps have been completed, the journal can progress through the configured process towards posting.

General Journal Entry Verification is SAP S/4HANA functionality for controlling the review of general journal entries before they progress to the posting stage.

Organisations can configure workflow conditions, verification steps and responsibility according to their financial-control requirements.

Its purpose is to make journal review part of a structured SAP process.

Yes.

SAP S/4HANA provides General Journal Entry Verification functionality that can be configured to route relevant journal entries for approval.

However, journal approval is only one part of journal management.

Organisations may also need to consider Excel preparation, early SAP validation, segregation of duties, supporting documentation, high-volume processing and audit reporting when evaluating the wider process.

Journal entry upload moves prepared journal data into SAP.

Journal entry verification controls whether a journal requires review and approval before it moves to posting.

A complete journal management process goes further by connecting preparation, SAP validation, supporting evidence, approval, posting and audit reporting throughout the journal lifecycle.

Yes.

Finance teams can continue using Excel as the preparation environment while applying a controlled approval process around the journal.

The level of integration depends on the solution used.

With Promenta’s SAP-integrated Excel Add-In, finance users can prepare journals in Excel while accessing SAP-connected picklists and validation, perform a simulated posting and submit the journal into the approval workflow without separating Excel preparation from the wider SAP control process.

General Journal Entry Verification is the native SAP S/4HANA Fiori capability for controlling the review of general ledger journal entries before they are posted. It was introduced with SAP S/4HANA 1709 and is configured through the Manage Workflows for General Journal Entry Verification Fiori app. Organisations can define which entries require review, who should approve them, and how exceptions are handled. Its purpose is to make journal approval part of a structured, traceable SAP process.

For a broader view of how this capability fits into the wider journal management process, see our guide to the SAP journal entry approval workflow.

Yes. Journal entry approval workflow capabilities are available in both SAP S/4HANA and SAP ECC. In the SAP ECC environment, organisations can configure journal entry approval through workflow-based controls similar in principle to S/4HANA General Journal Entry Verification. Promenta’s journal management solution operates natively inside both SAP ECC and S/4HANA, providing the same pre-approval validation, configurable routing, segregation of duties, and audit trail capabilities across both environments.