Year-end in SAP is categorically different from any other operational period. Financial period-close runs that only execute once a year. Batch jobs that have not been tested since last December and may have changed in runtime because a year’s worth of data has accumulated. Auditor access to systems during the reporting sprint. A business that has no tolerance for downtime between mid-December and the first week of January.
Most SAP landscapes drift throughout the year. Batch schedules get adjusted informally. Thresholds get muted. Jobs that were once Tier 1 get reclassified or forgotten. Certificates get close to expiry. RFC destinations point to systems that were decommissioned. None of these issues surface during normal daily operations. They surface at year-end, under load, when the team has the least capacity to deal with them.
This guide contains 30 questions to work through before the year-end window opens. Some will take five minutes to answer. Others will reveal conditions that need several days to address. That is the point of running the review in November rather than December.
How to use this guide ?
Run through the questions in a structured session with the SAP Basis lead and at least one business process owner for each major functional area. Record the answer to each question, not just whether it is satisfactory. The record is the documentation that supports the year-end readiness sign-off and provides context for the operations team during the closing period.
Questions that produce unsatisfactory answers need a remediation owner and a deadline before year-end. Not every question will reveal a problem. The ones that do deserve a named person and a completion date, not an action item that sits in a shared document.
Timing: run this review no later than six weeks before your year-end closing window. Some remediation items, particularly sizing changes or security note applications, have lead time.
| Section 1 of 6 · HANA and database health · Questions 1 to 6 |
Q1. What was the peak HANA memory utilization during the last month-end, as a percentage of the allocation limit?
Not the current utilization and not the daily average. The peak during month-end processing, which is the closest available proxy for year-end peak load. If that number was above 82%, year-end will very likely push it higher. Year-end close involves a full year of data in the working set, not just the last month. A system that reached 84% at October month-end has a meaningful risk of approaching the allocation limit in December.
Unsatisfactory: peak above 80% with no sizing review scheduled. Remediation: initiate a sizing conversation with the infrastructure or cloud team immediately. Hyperscaler instance type changes require planning and maintenance windows. On-premise memory upgrades require procurement. Neither happens in a week.
Q2. When was the last successful complete HANA data backup, and is the log backup chain intact?
Check M_BACKUP_CATALOG filtered for complete data backups. The last successful one should be within 24 hours. Then check whether the log backup chain has any gaps: a sequence break means point-in-time recovery is impossible for the period after the gap. Both conditions are straightforward to verify and both have serious recovery implications if they are not satisfactory before year-end.
A backup problem discovered during year-end close, when the team is under maximum pressure, is a far worse situation than one discovered in November with time to diagnose and fix the underlying cause.
Q3. How much storage runway remains on the HANA data volume at the current monthly growth rate?
Query M_DISK_USAGE for the current data volume size. If monitoring has been collecting this metric, use the trend to calculate the monthly growth rate and project forward. Year-end generates more data than typical months: period-close postings, year-end accruals, audit adjustments. If the current runway without those additions is less than four months, storage expansion needs to be in the plan.
Q4. How many delta merge failures occurred in the last 30 days, and what is the pending merge backlog?
Query M_DELTA_MERGE_STATISTICS for merge_reason = ‘MERGE_ERROR’ over the past 30 days. A delta merge failure count above zero is not always critical by itself, but a trend of increasing failures indicates that the auto-merge process is being interrupted, typically by resource contention. A growing pending merge backlog degrades read performance on the affected tables. At year-end, when analytical queries against full-year data are running alongside batch processing, degraded read performance in the HANA column store is a direct hit on closing timeline.
Q5. Is HANA system replication lag within acceptable bounds, and when was the last replication failover test?
For high-availability environments running HANA System Replication, check M_SERVICE_REPLICATION for the current lag. Sustained lag above 10 seconds in SYNCMEM mode is a warning sign. The lag at any given moment is the de facto RPO if a failover were required. More importantly: when was the last time the failover was actually tested? A configuration that has not been tested since go-live is an assumption. Year-end is the worst time to discover a misconfigured Pacemaker cluster.
Q6. What is the row store memory trend, and when was row store reorganization last performed?
Row store memory in HANA does not release automatically on row deletion. Over a year of operations, row store tables that experience high insert-delete activity accumulate allocated-but-unused memory. Check M_RS_MEMORY for the trend over the last six months. If row store allocated memory has been growing without a corresponding increase in actual data, run ALTER TABLE … RECLAIM DATA SPACE on the largest row store tables before year-end. It releases memory without any data loss and without a system restart.
| Section 2 of 6 · Background job schedule and batch capacity · Questions 7 to 12 |
Q7. Which Tier 1 batch jobs ran significantly longer in October than in October of the previous year?
Pull SM37 history for October this year and October last year. For each Tier 1 job, calculate the average runtime for both periods. A runtime increase above 20% year-over-year is not a coincidence: data volumes grow, custom ABAP that was acceptable at lower data volumes becomes slow at higher ones, or a database index that was regenerated last year was not regenerated this year. Each of these is addressable before year-end if discovered now.
This comparison also identifies jobs whose year-end runtime can be estimated. A job that took 4 hours at October month-end and grew 15% from last year to this year will take roughly 4.5 to 5 hours at year-end when the full annual data volume is involved. That estimate belongs in the year-end batch schedule planning.
Q8. Are there jobs configured as daily in SM36 that have not produced a new instance in the past 14 days?
A job that stops running silently is one of the harder failures to detect without monitoring. The job exists in the schedule. Nothing is in a failed state. The absence of recent instances is only visible if someone specifically checks for it. Scan SM37 for jobs with a daily schedule and filter for the last 14 days. Any daily job with zero instances in that window has a problem: it may be paused, the job server may be unavailable, or the schedule was inadvertently deleted.
Q9. Has the year-end-specific batch job schedule been prepared, reviewed against this year’s business calendar, and signed off by the relevant process owners?
Year-end close has a batch schedule that is different from the monthly close schedule. More jobs, longer windows, different dependencies, different server group assignments in some cases. This schedule is usually maintained by the Basis team based on previous years’ schedules. It needs to be reviewed against the current year’s closing calendar, particularly if the year-end falls on a different day of the week than last year, which changes which jobs need to run over which weekend.
“Signed off by process owners” means the finance close team, the logistics team, and any other function with year-end-specific processing has confirmed the job list and the timing. Not that the Basis team sent an email and did not receive any reply.
Q10. Are there jobs in SM37 with a failed or aborted status that have been in that state for more than five business days without a corresponding incident ticket?
This question is uncomfortable because the answer in many environments is yes. Jobs fail, get noticed by the team, and do not get formally resolved if the immediate impact is not visible. Over time, these known-but-unresolved failures accumulate. Before year-end, clear the SM37 failed job list. Either fix the jobs or formally document why they are no longer needed and delete them from the schedule. A failed job that has been in SM37 since September with no ticket is an audit finding waiting to happen.
Q11. Is the background work process pool on each application server instance sized for the year-end concurrent batch load?
Month-end batch and year-end batch are different in concurrent job count. Year-end often runs more concurrent jobs simultaneously because multiple functional areas are closing in parallel. Check whether the current background WP count per instance is adequate for the highest concurrent job count in the year-end schedule. If the year-end schedule has 18 concurrent jobs planned and the instance has 15 background work processes, four jobs will queue at every point during the peak window.
Q12. Have the predecessor-successor dependencies in all Tier 1 job chains been validated for this year’s schedule?
Job chains break when schedules change. A Tier 1 job chain where Job B starts after Job A’s completion is correct when Job A takes 3 hours. When this year’s data volume pushes Job A to 4.5 hours, Job B’s start shifts by 1.5 hours, and everything downstream of Job B shifts accordingly. If the year-end schedule has hard external deadlines (regulatory reporting, bank cutoffs), the chain timing needs to be revalidated against this year’s estimated runtimes, not last year’s actuals.
| Section 3 of 6 · Interface and integration layer · Questions 13 to 18 |
Q13. What is the current IDoc error rate by message type, and how does it compare to the same period last year?
Pull BD87 or WE05 filtered for the last 30 days. Calculate the error rate (errors divided by total volume) for each high-volume message type. Compare against the same month last year if the data is available. An error rate that has increased year-over-year on a specific message type indicates a gradual degradation in either the data quality from the sending system or the processing configuration on the receiving side. At year-end, when IDoc volume spikes for invoicing, shipping notifications, and financial postings, a 2% error rate becomes a much larger absolute error count.
Q14. Are there RFC destinations in SM59 that point to systems which have been decommissioned or which no longer accept connections?
Run the RFC connection test for all type 3 RFC destinations configured in production. Destinations that fail the connection test and have not been used in the last 90 days are candidates for decommissioning. Destinations that fail but were used recently indicate a broken integration that may be affecting business processes. This check takes an afternoon and reveals both dead configuration that can be cleaned up and broken integrations that need attention before year-end.
Q15. Do any SSL certificates on RFC destinations, API endpoints, or middleware connectors expire before the end of Q1?
An SSL certificate that expires on January 15th is not a year-end problem. It is a January 15th problem that will occur during the period when the team is finalizing year-end close and has the lowest capacity for an emergency fix. Pull the expiry dates for all certificates in use on production interfaces. Any certificate expiring before the end of March warrants renewal before year-end rather than after.
Q16. What is the current qRFC queue status on all production interfaces, and are there any blocked queues?
Open SMQ1 and SMQ2. A blocked queue (status SYSFAIL or CPICERR) stops all message processing for every entry in that queue behind the blocking entry. If there are blocked queues in production that the team knows about and has been managing around, year-end volume will make the backlog larger and the workaround more time-consuming. Fix the underlying blocking condition before year-end.
Q17. For the three highest-volume interfaces, when was the last time the full end-to-end message flow was tested from sending system to confirmed application posting?
A connection test confirms network reachability. An end-to-end message flow test confirms that data is actually being processed correctly through the full integration chain. These are not the same test and they fail independently. Before year-end, run a test transaction through each of the three highest-criticality interfaces and verify the output in the receiving system. If any of them fail this test, the failure is discovered in November with time to fix it.
Q18. Are all integration platform certificates, API keys, and middleware credentials (including those on SAP BTP or Integration Suite) current and scheduled for renewal?
BTP-hosted flows and Integration Suite connectors use credentials that expire on their own schedules, independent of the ABAP system’s certificate management. A BTP service credential that expires in mid-December will break any integration that uses it, with no indication on the SAP side beyond a failed flow instance. Pull the credential expiry dates from the BTP subaccount cockpit and add any that expire before March to the renewal list.
| Section 4 of 6 · System performance and capacity · Questions 19 to 23 |
Q19. What are the five programs with the highest average dialog step duration in the last 90 days?
Pull this from the workload monitor or from STAD statistics. For each of the five programs, determine whether the duration is expected (a program designed for long-running analysis) or anomalous (a program that should complete quickly but has regressed). Programs with anomalous runtimes consume dialog work processes longer than they should, reducing effective capacity during peak load. Identified before year-end, they can be investigated and potentially optimized. Identified during year-end close, they are firefighting.
Q20. What is the peak extended memory (EM) utilization on each application server instance, and what happens to sessions when EM is exhausted?
Extended memory is shared across all sessions on an application server instance. When it is exhausted, sessions fall back to roll file storage on disk, which is orders of magnitude slower than memory. Check the ABAP memory monitor (ST02) for each production instance and look at the maximum EM utilization observed over the last 30 days. Year-end brings more concurrent users and more memory-intensive sessions (large reporting jobs, annual analysis reports). If peak EM utilization is already above 75%, year-end will push some sessions into roll file territory.
Q21. What is the current table buffer hit ratio on each application server instance, and has it degraded compared to last year?
Open ST02 and check the quality column for the table buffer. Hit ratios below 98% indicate that the buffer is too small to hold the full working set of frequently accessed tables, and reads that should come from memory are going to the database. In a system with many concurrent users during year-end, the accumulated database reads from buffer misses create measurable load. If the ratio has degraded from last year, either the buffer is undersized relative to a growing working set or a buffered table has grown significantly and needs attention.
Q22. Is the dialog work process pool on each application server instance adequate for the expected peak concurrent user count during year-end?
Year-end often brings users who are rarely active otherwise: department heads reviewing annual figures, auditors with temporary system access, executives running year-end dashboards. The peak concurrent session count in December may be 30% higher than any other month. Check AL08 for the peak concurrent user count from last December and compare against the current dialog WP pool size on each instance. If last year’s peak pushed any instance above 80% WP utilization and the user count has grown since then, additional dialog work processes may need to be configured before year-end.
Q23. Has the short dump rate in the last 30 days increased compared to the same period last year, and are there any recurring dump classes?
Open ST22 and compare dump counts: this October versus last October. An increasing trend indicates growing instability, often from custom ABAP programs that have not been adapted to data model changes or volume increases. Look specifically at dump classes: MEMORY_NO_MORE_PAGING and TSV_TNEW_PAGE_ALLOC_FAILED point to memory pressure, TIME_OUT indicates programs exceeding step time limits at current data volumes. Both become more frequent at year-end when data volumes are largest.
| Section 5 of 6 · Security and access hygiene · Questions 24 to 27 |
Q24. Are there users with SAP_ALL or emergency access authorizations whose access has not been formally reviewed in the last 90 days?
Pull the user list filtered for users assigned to SAP_ALL or to emergency access roles. For each user, verify that their access is still required, is being actively used for the intended purpose, and has not become a dormant broad-access account. Year-end brings external auditors who specifically look for overprivileged accounts. Remediating this in November is preparation. Remediating it in January under audit pressure is reactive.
Q25. When were the passwords for SAP service users, monitoring users, and RFC technical users last rotated, and is that within the organization’s policy window?
Service users and technical users in SAP are often excluded from standard password rotation policies because rotating them requires updating RFC destination configurations and interface connection strings. Over years, these credentials accumulate as effectively permanent. Before year-end, verify the last rotation date for each service account and RFC technical user, confirm it falls within the organization’s security policy, and schedule rotation for any that do not. Document the rotation to satisfy any audit requirement for credential management evidence.
Q26. Are there open SAP Security Notes rated High or Very High that have not been applied to production?
Check the SAP Security Notes launchpad for any notes with a CVSS score above 7.0 that apply to the SAP components running in production and have not been applied. Critical security patches should not be deferred to post-year-end. The year-end period, with auditor system access and heightened external interest in financial systems, is the highest-risk period for a security incident. Apply critical security notes before year-end, not after.
Q27. Is the access provisioned for year-end auditors limited to what they actually need, and is there a defined removal date?
External auditors require read access to specific transaction data, reports, and documents during the year-end audit. That access is often provisioned broadly because scoping it precisely takes time. Before year-end, define the minimum required access for each auditor role, confirm it has been validated by the security team, and set a removal date in the access provisioning record. Auditor access that was granted in December and not revoked until April, because the removal step was missed, is a finding in the following year’s audit.
| Section 6 of 6 · Monitoring configuration and recovery readiness · Questions 28 to 30 |
Q28. Have alert thresholds been reviewed and adjusted for year-end load profiles, and are maintenance window suppressions configured for the closing activities?
Thresholds calibrated to daily load averages will generate false positives during year-end batch processing when memory, CPU, and work process utilization are all legitimately higher than usual. Before year-end, review the thresholds for HANA memory, dialog and background WP utilization, and batch job duration, and adjust them for the expected year-end peaks. At the same time, configure suppression windows for the planned year-end closing activities so that maintenance-window events do not generate on-call pages during activities that are expected to produce elevated system load.
Also verify that the on-call escalation path is current. Phone numbers change. People change roles. The escalation tree configured 14 months ago may route to someone who left the organization in August. Test the escalation path end-to-end before the year-end window, not during it.
Q29. When was the last successful recovery test performed, what was the measured RTO, and does that RTO fit within the year-end business continuity requirement?
A backup that has never been tested for recovery is an assumption. The year-end period, when downtime would have the highest financial and reputational impact, is not when assumptions should be tested for the first time. If the last recovery test was more than six months ago, schedule one before year-end. The test does not need to be a full production recovery. A targeted restore of a representative data set into a test environment, timed from start to confirmed data availability, establishes the RTO with evidence rather than estimation.
Q30. Is backup storage capacity sufficient to hold all backups through the year-end period plus the required regulatory retention window without rollover conflicts?
Year-end generates more backup data than any other period: full data backups running alongside log backups running alongside archive logs, all at a time when the database is growing faster than average due to year-end posting volume. Calculate the storage requirement: current data volume plus expected year-end growth, multiplied by the backup retention policy, plus the log backup volume at peak log generation rate, multiplied by the backup retention window. If that number approaches the available backup storage capacity, either the storage needs to be expanded before year-end or the retention policy for older backups needs to be adjusted. Discovering a full backup volume during year-end close is an avoidable incident.
What to do with the results
After working through all 30 questions, the answers fall into three categories. Questions with satisfactory answers contribute to the readiness sign-off and need no further action. Questions with unsatisfactory answers but low remediation effort should be addressed immediately. Questions with unsatisfactory answers that require significant effort, infrastructure changes, or external coordination need a named owner, a realistic completion date, and an escalation path if the date cannot be met.
The most common pattern is that 22 to 25 questions have satisfactory answers, three to five have quick fixes, and two or three reveal conditions that require real remediation effort. The ones requiring real effort are the ones that justify running this review six weeks before year-end rather than six days before.
Run the review again at two weeks before the year-end window opens. Not all 30 questions, just the ones that were unsatisfactory at the first review, plus the monitoring and backup questions which are time-sensitive. The second review confirms that the remediation items were addressed and that no new conditions have emerged since the first review.
The 30 questions in this guide do not guarantee a problem-free year-end. They do guarantee that the problems which are findable before year-end have been found. The ones that only appear under full year-end load are a different category of risk and require real-time monitoring, not advance review, to catch.
Redpeaks monitoring provides the data needed to answer most of these questions in minutes rather than hours, with trend views, alert history, and cross-system correlations accessible from a single interface. See how Redpeaks supports year-end readiness.
