Jumping right in...
Is there a way to insert regexp's in the billing script to extend functionality to all users?
No. See explanation at the end.
Just wondering if pharos scripting accepts regular expressions.
You could call an external plugin, but the Pharos scripting language does not have built-in reg ex features or capabilities.
Adding an email address is the most common mistake when people are entering credentials (even though there is an ex. jsmith in the popup dialog ) any advice would be greatly appreciated.
This has been my experience as well, but unfortunately there is not a way to implement a server side script to accomplish what you are looking for. You could parse the username entered in the field and flat-out reject it if it includes the @domain.edu. Paired with a script that notifies the user of the status of their job, it would help train users by telling them what they did wrong right away, and instructing them on how to do it correctly.
Unless a change has been made that I have overlooked (or was never published in the change log), the cost center permission lookup is completely separate from the billing plugin and from the reg-ex features found under the system section of the Pharos Admin. As such, the username has to be submitted identically to the username in the Pharos database, and there is not a scriptable means of modifying the username on the fly. There are methods for controlling this, and what I usually see happen - since this is most commonly associated with staff/faculty accounts - is that the popup username field is removed altogether.
This sometimes means setting up a separate queue(s) for the cost center printing, but usually this is not a major obstacle since users normally log in as themselves, and it actually introduces a higher level of security as users can no longer type in just any user ID to gain access to that individual's cost center permissions. I believe that going this route only leaves 1 minority group of users that could be problematic, and those are users with domain joined Macs who have logged into their workstation with email@example.com. There is a workaround for this as well, but I've only seen it come up once in 10 years.
Removing the option to enter a job owner name usually takes care of the problem, and if that is not an option, a script that flat out rejects logons with @domain.edu should shape user behavior toward success. Let me know if you have any questions!