"Nobody touches my accounts!" A statement often heard when planning implementations of integrated job costing and accounting solutions in organisations that previously ran separate systems for these. Finance teams are adamant that nobody outside of their team should be able to trigger any accounts postings.
What on first sight appears to be a valid concern by the finance department is nevertheless in many cases already being overtaken by reality in their current procedures.
It's not an issue where job managers generate job budgets or purchase orders, which don't create postings to the GL. But project managers often have the responsibility already to generate documents like sales invoices and send them out to their clients - rather than just drafting them - with the finance department then only recording those invoices in their financial software. The detail that these project managers don't actually have write access to the financial software doesn't alter the fact that the documents that they send out are legally binding documents and thus have to be recorded in the accounts. If a mistake has been made in any of those invoices, the wrong invoice still has to be recorded by the finance team and be corrected by generating a credit note and amended invoice.
Because of that reality in their current systems it would be paradox to introduce an integrated system with the purpose of streamlining the workflow and reducing the duplication of data entry, but then restrict the functionality job managers have access to, thus reversing these benefits. That is why many companies decide to give their project managers access to functions such as AR Invoicing, having put in place precautions to minimise the possibility for errors:
When the software is set up initially, accounts departments are able to construct the system in a way that postings to the accounts are under the complete control of the software and cannot be overwritten by project managers. Looking again at the example of a sales invoice, it is usually only a case of setting up a link to one GL account for the debit transactions (Accounts Receivables or Debtors) and - depending on the state - one or two for the credit postings (Sales Revenue and Tax*). If the integrated software does not give project managers the option to overwrite any of those codes, there is a good argument for them to be able to enter sales invoices.
If - in addition to the example of an AR invoice - users are also responsible for deciding which job related bought-in costs are covered by this invoice, there is not much to say against giving them access to this part of the accounts posting either. In many enterprises that use separate accounts- and job costing-systems the finance team will ask project managers anyway for details of what is and what is not yet covered by AR invoices (what stays in or comes out of WIP). Therefore again if project managers are restricted from overwriting the system controlled GL accounts for Work in Progress or Cost of Sales, letting them decide on a job level what should be transferred, will increase workflow with the risk of mispostings minimised.
There will of course always be individual cases of users who require - initial - handholding by the finance team and the finance team has to retain overall control and responsibility. There will always be human errors, but mistakes also happen within accounts departments AND mistakes can be corrected.
Companies that have given this kind of access to their project managers have all experienced an increase in work economy. Financial managers can spend more time managing finances rather than inputting data and project managers see an increase in their job responsibility and work satisfaction.
Summarising all the points outlined above, the answer to the question in the title has to be: It makes much sense when introducing an integrated job costing and accounting solution to give users outside of the finance department limited access to financial functions, if they have been laid out in the system and the system has been set up with a strict control over them.
No comments:
Post a Comment