Programming and auditing

A recent post on Coding Horror on pseudocode reminded me of my work as an internal auditor. You might think it’s strange that a blog post on a programming/development technique would make me think of auditing – well, you’re right. It is a little weird. But hear me out.

Pseudocode is called that because it’s not really code. It looks similar to code but it’s written in plain English rather than something the computer can understand. The point of it is to develop the logic of a program first before getting into the nitty-gritty of actually creating something workable. You’ll be better able to see and fix high-level problems at this stage than you would be when you’re wading through a morass of source code.

This to me is a lot like documenting a transaction cycle from scratch. You start at a high level and just get the bare bones down on paper to understand it from that perspective. You have discussions with the staff involved at each stage and understand from their point of view the role they play. As you have these discussions you’re getting deeper into the step-by-step procedures involved. You’re fleshing out the documentation and starting to identify the key controls.

Customer order received (on account)
If customer exists in system
	If customer is below credit limit
		Enter order
	Else
		Return to customer account manager
Else
	Send credit application to customer
	Receive complete application
	If customer credit history is good
		Set up customer in system
	Else
		Reject customer order

From there you delve a little more into the details. How are orders received? Who receives them? Who sets up the customer in the system? How is credit checked and by whom? Answering those questions will illuminate the controls and the segregation of duties within the process, and in a way you start to move from pseudocode to source code. You can’t test a transaction if it’s in pseudocode stage like you can’t run pseudocode in the development process. Once you have a testable, documented process it’s good to go.

So there you have it. There is a connection between the type of thinking required of a programmer and that of an auditor. This must be why I was able to make the transition from the Computer Science program into the Accounting program at university!