Notes

C.1 – Source of balance to support the general ledger
The reconciliation is supported through a combination of system-generated reports and detailed manual schedules. The “User Interface BD” tab represents the portion of the balance substantiated with valid documentation at the time of reconciliation preparation. The “User Interface RI” tab includes items considered open during the initial review phase due to lack of immediate visible backup; however, these were followed up on by the control owner with responsible stakeholders. The aggregated balance of both tabs ties back to the SAP GL, indicating completeness at the summary level. Supporting documentation for individual line items was either attached in separate files or reviewed by the control owner at the time of preparation. Certain balances trace back to prior platforms (like Oracle), or include sensitive PII, and thus are not fully captured in the centralized file, though the preparer's evaluation was considered.

C.2 – Controls addressing accuracy and completeness of documentation/schedule
The reconciliation and supporting schedules do not directly stem from a defined business process control. However, a control exists whereby the preparer compiles the reconciliation using SAP data and/or other legacy system inputs and flags open items for review. The control owner performs a completeness check by identifying and following up on unsubstantiated balances, thereby validating that all material movements are appropriately addressed. This forms a compensating check on completeness and accuracy despite the absence of a formal automated control.

C.3 – System-generated report specifics (if applicable)
Some supporting documentation originates from SAP; however, since the line items are spread across platforms (SAP and Oracle), and certain workings are performed offline or through manually maintained schedules, consistent system T-codes and extraction parameters were not always used. Review steps mainly involved tying the totals back to SAP GL (which has been done successfully), and verifying the validity of items either through attached documentation, follow-ups, or logical checks by the control owner. Due to the complexity of data flow across systems, report logic testing was not deeply documented but deemed sufficiently addressed via reconciliation tie-out and management’s assessment.

C.4 – Steps performed by reviewer when no underlying control exists
Given the mixed nature of source data, the reviewer (control owner) performed line-by-line checks to identify whether appropriate documentation existed. This included:

Verifying if each item had a visible backup (either attached or available offline).

Flagging open items for which documentation was not visible, followed by direct outreach to responsible individuals for further inputs.

Accepting certain figures as derived from historical systems (e.g., Oracle) based on management explanation and historical context.

The GL balance was validated as complete through tie-back to SAP and cross-verification with other records where feasible.

C.5 – Mathematical accuracy of manual documentation
The schedules, particularly the User Interface BD and RI tabs, were reviewed for footing and cross-footing accuracy. The total from these tabs correctly adds up to the SAP GL balance. While some items have underlying workings involving calculations, we relied on the preparer’s validation and spot-checked selected items. The overall mathematical integrity of the reconciliation has been reasonably demonstrated.

C.6 – Third-party report review (if applicable)
Not applicable in this case, as the reports/schedules used were internally generated or derived from entity-controlled systems. No third-party documentation was directly relied upon in forming the reconciliation.