How to ensure segregation of JE duties via GL65/GL165

In addition to GL40, we have accountants who use GL65 to upload journal entries. We have been wrestling with how to ensure (and prove to auditors) the segregation of duties with this screen: That one person enters a journal but a different person releases it. When a GL65 journal is released, GL165 puts into both the Operator and Release Operator fields the ID of the user who ran GL165. So it is not clear that one person entered the journal and another released it. (With GL40, of course, it identifies the Operator and Release Operator separately.) How can we know and show that the two tasks were done by two different people? Also, is there a way to differentiate between GL65 journals that were uploaded via the Excel add-ins and those imported with ImportDB? Is there a way we can address this via security restrictions (we are LAUA)? Is there anything in LS9 that we can look forward to using to address this? Thanks for any help or advice you can offer.

LMS Customer Series Presentation_March 2021.pdf

Find more posts tagged with

Infor Lawson Financials Group - Discussion

Comments

lbecker

You can edit the ability to use Function Codes (FCs) in LAUA to control this.
For example,
GLENTRY can add and edit a journal in GL40, but not release it.
Allowed FC's Restricted FC's
ACINP+-X R

GLSUPERVISOR can release them, but not add or edit them them
Allowed FC's Restricted FC's
INP+-R ACX

You can do similar actions for GL65, GLENTRY can add records GL65, but can only use "INP" on GL165. A supervisor can use "ACDINPVSR" on GL165, but can only inquire on GL65.

Only batch service accounts and support staff should be able to use importdb from a command line. Also, screen IMDB.1 is a screen adaptation of importdb, and should have the same restrictions as importdb.

The proof of separation of duties is in the security reports. However, the reports are very long and a little foggy, so the auditor will say "What's this crap?" He will need a little training in Lawson.

Legacy Contributor

Thanks! We do much of that already in most cases. But we have some departments that are smaller and staff need to be able to both enter and release journals. That prevents us, in those cases, from enforcing SOD with the security arrangements you describe. I might enter today a journal that you release. You might enter tomorrow a journal that I release. We both have the ability to do both functions, but we maintain SOD on each particular journal by following procedure. So we need a way to prove to the auditors that we've done that.

The GL40 path works fine as someone can have the ability to both enter and release, and the entry operator & release operator are identified separately in GLCONTROL. But for journals entered through GL65, it's not clear who entered the journal ... since GL165 put the ID of the person running GL165 into both the operator & release operator fields. So we're looking for an alternative that does the same sort of thing ... somehow. Hoping someone else has run into this and can share how they've handled it.

Legacy Contributor

This isn't as foolproof as audit tables, but you could have the person that prepared the JE that is entered into GL65 key their name in an unused field, maybe the reference or document field. Then there is a distinction between who keyed/prepared the journal entry and who released it, and one that you can track and show the auditors.

Legacy Contributor

We use ProcessFlow for approval of journal entries on GL40. We defined standard source codes that are put on pre-approved journals, so they bypass ProcessFlow approval. We also only allow end users to either upload or enter journals entries on GL40. We use GL65 for interfaces and as part of our ICE controls, we require each interface to send a header and trailer record that lists a record count and total debits and credits. If that all matches and there are no errors when the GL165 is run, it will interface to GL as a released journal. Only members of the Finance Operations Support team have access to GL65 and those team members do not have update access to GL40. Any other GL65 "journals" would be considered non-routine and most often less than $50K so also bypass ProcessFlow. We allow our users to enter and release journals, but if non-standard and greater than $50K, the journals are reviewed and approved first. We also have mitigating controls on the back end. We have a JE Checklist tool that assigns a 5-digit numerical code to all routine journals. We put that code in our journal headers so after all the journals a posted, a file is created to be uploaded to our JE Checklist. This tool matches up expected journals with the actual journals, as long as they use the code in the journal header. The non-routine do not have a code, but the ProcessFlow approval information is extracted as well and the journal control information. The non-routine journals all have to be reviewed and signed off as well as all interface journals. This tool helps provide a safety net for unexpected absences as well. The routine journals have a Preparer, Reviewer and Approver identified up front.

Legacy Contributor

I should also mention that we connect an end user in Lawson to the Supervisor Org Structure in HR so that when a user releases a journal that meets approval criteria, an email is automoatically generated to the supervisor with a link and header information on the journal. They can click on the link and review the entries and have the option to approve or deny (unrelease).

lbecker

We restricted GL65 for individual users to create/edit transactions.
We load GLTRANSREL with an automated, unattended interface, using only data coming from external systems. Once in a great while, a manager must delete an entire Run-Group because of some error. We require the sending system to resend corrected data. That's my suggestion.

If a person has the ability to both enter transactions in GL65, and run process them in GL165, then you are not compliant for SOD. Even though everybody voluntarily follows the rules, it is not compliant.

If you MUST use GL65, get a higher level manager to sign off that this is a known risk and there is no program functionality to enforce SOD, and that he finds this to be an acceptable business risk. That should keep the auditors at bay until the next audit.

If the manager doesn't sign off, then you are non-compliant, and the auditor gets to smack a ruler on your knuckles! Just kidding!

0911060553270289.pdf

Copyright © 2025 Infor. All rights reserved.