We wrote on the various types of exceptions at each stage. We had also shared a laundry list of exceptions earlier.

http://faoblog.com/processes-ap-exception-management-types/

http://faoblog.com/processes-ap-exception-management-types2/

http://faoblog.com/processes-ap-exception-management-types3/

So, what would be the typical steps for processing of exceptions? At each stage, the following steps or some of these will be mandated:

  • Identify the exception
  • Look for a solution in the repository / prior learning database
  • If exists, provide a solution and move the transaction for further processing (like some vendor details, which can be pulled from an existing database)
  • Log the entry in a tracking log, this could be a manual list, (like at the scan center) or an entry in the workflow.
  • Identify the return entity, the person to whom this transaction has to be sent for rectification.
  • Route the transaction for resolution.
  • Receive the transaction post resolution.
  • Also, keep a check on the turnaround, and send appropriate / agreed reminders at pre-defined periodicity.
  • Once the transaction is received back after resolution, check again for completeness / other or additional requirements.
  • If needed send again for resolution.
  • Once fully resolved, move for further processing, which could be upload to ERP / for payment / as required.

This will have to be customized as per your client requirements and will apply to almost all processes, F & A and non-F & A as well. This might seem common information, however, reduction of exceptions is a critical process improvement area, and a lot of people actually ignore this area and end up losing their sleep as well.

We have enabled a button on the top of the first page, which will enable you share your posts. If you wish to write about any of the current streams, you can do it at http://faoblog.com/guest-post/. We will review your post and release it within 48 hours of your posting.