A Non-Coder's Guide to Interrogating a Financial System

Published on: Wed Feb 14 2024 by Ivar Strand

A Non-Coder’s Guide to Interrogating a Financial System

A common belief in financial oversight is that the internal logic of a software system is a “black box,” accessible only to IT specialists and developers. This leads to a concerning gap in assurance, as financial controllers and auditors often feel unequipped to question the technology that underpins their work.

This perspective is not correct. You do not need to be a software developer to perform a meaningful interrogation of a financial system. Effective oversight is not contingent on the ability to read code; it is a discipline of structured, logical inquiry. This article provides a practical framework for non-technical professionals to probe a system’s integrity.

The Principle of Indirect Inquiry

While a non-coder cannot directly audit source code, they can rigorously test a system’s behavior to deduce its underlying logic. The approach is to treat the system as a closed box and systematically analyze its responses to specific inputs and scenarios. The patterns that emerge from these tests reveal how the system is actually configured to handle key processes, controls, and exceptions.

This method moves the auditor from a passive recipient of system reports to an active interrogator of the system itself.

A Framework for Interrogation

The following checklist provides a series of practical actions and questions that a financial controller, auditor, or program manager can use to assess a financial system, regardless of their technical expertise.

1. Map the Standard Workflow (the “Happy Path”). Request a live demonstration of a single, standard transaction from end to end. For a payment, this would start with the initial request or invoice and end with the final payment confirmation. Document every user action, every screen, and, most importantly, every automated decision point the system makes. This establishes your baseline of how the process is supposed to work.

2. Systematically Test the Boundaries and Edge Cases. Once you understand the standard path, probe the exceptions. Use specific “what if” scenarios to test the system’s controls and error handling.

   • What if an invoice number is entered twice? Does the system flag the duplicate?
   • What if a payment request exceeds the pre-approved budget line? Does the system block it, or does it issue a warning that can be overridden?
   • What if a required date field is left blank? The system’s response reveals the integrity of its data validation rules.

3. Request a Walkthrough of Configuration Settings. You do not need to see the code, but you should ask to see the administrative interface where system rules are configured. Key questions include:

   • Where are the user roles and their specific permissions defined?
   • Can we see the screen where the payment approval hierarchy is set?
   • Where are the financial thresholds for different levels of approval entered and maintained? This provides direct insight into how the business rules are translated into system settings.

4. Perform Independent Recalculation. Identify a process that involves an automated calculation, such as applying a specific overhead rate, converting currencies, or calculating payroll taxes. Export the raw input data for a sample of these transactions and perform the calculation independently in a spreadsheet. Any variance between your result and the system’s output points directly to a potential flaw in its logic.

5. Reconcile Data Across System Boundaries. If the system sends or receives data from other platforms (e.g., a field-based beneficiary registration tool), verify the integrity of the transfer. Does the number of new beneficiaries recorded in the field tool for a given week exactly match the number added to the central payment system? A discrepancy indicates a potential silent failure in the data integration process.

From Inquiry to Assurance

The purpose of this framework is not necessarily to find every technical bug. It is to identify areas of ambiguity and risk that warrant further investigation. The documented results of these tests provide a solid, evidence-based foundation for discussions with IT teams and vendors.

Fiduciary responsibility does not end where the software begins. By applying this structured inquiry, non-technical leaders can fulfill their oversight duties, transforming passive trust in technology into active, demonstrable assurance.