In Administration under My Company, you maintain the system-wide basic settings of your ZEP tenant: appearance, email dispatch, company data for invoicing, bank details, letter paper, login/password policies, and roles and permissions. The box is available in all product lines. Individual sub-menu items appear depending on the licensed add-on modules.

You reach the area via Administration > My Company. You need the View permission in the Administration Area row of the Administration area in Roles & Permissions.

In the sub-menu General, you set the appearance of your ZEP, the default language, the number of items per table page and several system-wide security defaults.

You upload your Company logo (maximum 5 MB). ZEP displays it exclusively inside the web application: on the login page and in the top navigation of the running application. For display on printed reports, invoices and PDF exports, the Letter Paper is responsible — logo and letter paper are separate configurations.

Three color fields control the appearance of your ZEP. ZEP Color sets the primary accent color for buttons, highlights and header bars. App DarkMode Color sets the accent color for the mobile ZEP app in dark mode. Link color determines the color of links in texts.

You enter a hex color value or pick the color from the color palette. The Standard link at the ZEP Color field returns you to the ZEP default color. If you clear App DarkMode Color or Link color via the empty link, these fields use the ZEP Color.

Via the checkbox Show ZEP logo in black and white, ZEP displays its own logo in monochrome instead of the ZEP default colors. Particularly helpful when you have stored a strong accent color as ZEP Color and Link color and the original ZEP logo colors no longer fit harmoniously into the overall design. The setting affects the web application, not the uploaded company logo.

You choose between offer as an option, automatically redirect (ZEP always redirects to the SSL-encrypted connection) and do not redirect. ZEP recommends SSL throughout. When switching from automatically redirect to a different setting, all users must manually delete their ZEP session cookie in the browser — otherwise a new login is not possible.

Controls whether the browser-native password storage is allowed. Activation eases the daily login on the same devices. Deactivation makes sense on shared workplaces or under strict compliance requirements, so that login credentials do not end up in the browser cache.

You set the ZEP language for ZEP. The language setting also includes the language-typical formatting of date, time and decimal numbers. ZEP supports six languages: German, English, French, Spanish, Slovak and Turkish — plus several regional format variants such as Austrian German or British English formatting.

Employees, projects and contacts usually have the setting -Default- and therefore see ZEP in this global language. A different language can be set individually at three levels:

The login page follows the default language set here and nothing else. There is no language selector on the login page itself, and ZEP does not evaluate the browser language setting. The personal language only takes effect after sign-in.

You determine how many rows ZEP displays per paged table (project administration, employee administration and comparable lists). The default is 15. High values are only comfortable on large monitors — otherwise an unpleasant interplay arises between table paging and browser scrolling.

The setting does not affect fully displayed report tables or popup lists. A page break also only occurs when the next page would contain at least four entries.

A high number of entries per page also lengthens the page load. Since the first table page is already loaded when you open a menu item, switching menus feels noticeably slower as a result.

With this option you automatically display the stored company name in the header of every printed report — useful when the letter paper does not already transport the company details or when you want to distinguish tenants quickly.

With this checkbox you control whether ZEP keeps line breaks in multi-line text fields (for example project or task remarks) during the CSV export or replaces them by spaces. The default is oriented toward the fact that many spreadsheet tools (e.g. older Excel versions) interpret line breaks within a cell as a new data row — and thus the column structure of the export is lost. Activate the option when your target system can handle multi-line cells.

In the sub-menu Email, you determine how ZEP sends emails. The configuration screen is structured into two tabs: General (mail-server choice, configuration path and the section Settings for Emails generated by the ZEP mail client) and Display. Depending on the choice in the General area, two configuration paths are available: ZEP mail server with [email protected] or your own mail server (your own SMTP server, optionally with OAuth).

In the General area, you choose which mail server ZEP uses for automatically generated emails: planned-hours warnings, overtime notifications, ticket-system emails and comparable collective mails. Two configuration paths are available. We recommend the ZEP mail server because it accepts mails immediately and processes them in a background queue. The ZEP entry does not wait for the dispatch. With your own mail server, ZEP has to hand the mails over synchronously, which can delay the entry by a few seconds depending on the provider (especially when saving time bookings that trigger follow-up mails).

Default configuration without additional effort. Under Mail server, select Use ZEP mail server. ZEP sends automatically generated emails with the fixed sender address [email protected]. This variant is the right choice when you do not need your own company domain as sender.

You choose Use your own mail server and store your SMTP server with the corresponding access data: Server, Port, Use secure connection, Username and Password. The sender address must belong to your domain — [email protected] is not allowed because our SPF record only allows ZEP systems to send.

For modern cloud mailers (Microsoft 365, Google Workspace), you secure the access via OAuth instead of username and password. ZEP supports four OAuth paths — details follow in the next section.

When you have chosen Use your own mail server and want to connect ZEP to a cloud mailer via OAuth, choose one of four providers in the OAuth field: Microsoft (OAuth2 SMTP) (classical SMTP dispatch with OAuth authentication), Microsoft (Graph API) (dispatch directly via the Graph API, without SMTP), Google, or General (generic OAuth provider).

For dispatch via Microsoft 365 by SMTP with Azure OAuth, register ZEP once as an app in Azure and store the access data in ZEP.

Steps in Azure:

Steps in ZEP under Administration > My Company > Email > Change settings: choose Use your own mail server and fill in the fields:

With OAuth, ZEP sets Port (587) and Use secure connection (STARTTLS) automatically. No password is needed.

Click Save, then click the external-link icon — you are redirected to the Office 365 sign-in page. After a successful sign-in, you automatically return to the mailbox page in ZEP. Setup is complete.

Alternative without SMTP protocol: ZEP sends the mails directly via the Microsoft Graph API. This variant bypasses SMTP-specific restrictions of your Microsoft 365 environment and is often the preferred path under strict compliance requirements.

Steps in Entra ID (Azure):

In ZEP under My Company > Email > Change settings: choose Use your own mail server > Microsoft (Graph API) and transfer the following data from Entra ID:

For dispatch via Google accounts, register ZEP as an app in the Google Cloud Console. A detailed guide on the Google app registration is available at support.google.com/cloud/answer/6158849.

You register the ZEP mail dispatch as an app via cloud.google.com/console. There you obtain OAuth-ID and OAuth-Secret, which you enter in ZEP. The redirect URL is shown in the ZEP settings as soon as you switch to Google OAuth — usually https://www.zep-online.de/zepXXXXXXXXXX/view/oauth2smtp.php, where you replace your ZEP name.

Steps in ZEP under Administration > My Company > Email > Change settings:

After saving an arrow icon appears in a box. There you sign in to Google once and grant the required permissions via pop-up. Via the letter icon you then send a test mail for verification.

Once established, ZEP keeps an OAuth connection alive by itself. There is no fixed expiry date. The connection only breaks when the other side invalidates it, for example after a password change of the stored account, after consent has been withdrawn, after a changed sign-in policy, or when the app registration has been deleted.

ZEP shows no status for this and gives no advance warning. You notice it when emails no longer arrive. This is how you restore the connection:

The stored access data remain unchanged in the process. You only sign in again.

For emails that ZEP generates automatically (planned-hours warning, overtime notification, ticket updates, hour-report confirmation) you store Sender name, Sender address, Reply-to name and Reply-to address. Recipients see the following information in their mail program:

Since usually nobody is expected to reply to these automatically generated mails, a noreply reply-to address is often used. With an active special outgoing mail server, typical values are: sender name ZEP, sender address [email protected].

This information for sender name, sender address, reply-to name and reply-to address applies not only to emails ZEP generates automatically, but also to emails you send manually via the ZEP mail client, for example when sending invoices or offers.

By default, ZEP opens the local mail client of the user (Outlook, Notes, Apple Mail) when an email address is clicked. Via the checkbox Use ZEP mail client, you alternatively activate the built-in ZEP mail client. Advantage: no length limit of the email, consistent surface independent of the local program.

Via the field Delimiter for e-mail addresses, you globally define whether a comma or a semicolon stands between multiple recipients — some mail programs only accept one or the other. As soon as employees have saved their own setting in their profile, the global default no longer applies to them.

In the Display area, you design header and footer of all ZEP-sent emails via the HTML editor in Mail-header and Mail-footer — typically logo, company information and legal footer. Both editors accept HTML including inline CSS for formatted display.

Via the checkbox Show e-mail in full width, you choose whether ZEP shows the mail template across the full browser width or centered with fixed width. Full width suits templates with wide tables, fixed width suits classical letter layouts.

In the sub-menu Company data, you store the master data of your company. ZEP uses these data as the invoice sender for ZUGFeRD and XRechnung creation, for the Swiss QR code, and as placeholder variables in your letter paper. If your company data changes (legal form, address, board members), maintain them here — the update is automatically applied to all letter paper templates that contain the corresponding placeholders.

Mandatory fields for every legally correct invoice output: Name, Address line 1, optional Address line 2, ZIP Code, Location and Country code. These data appear in the sender area of printed reports and in ZUGFeRD/XRechnung metadata. The country code additionally controls country-specific fields (for example Swiss-specific fields such as BESR-Id).

Fields for Phone, Fax, Email and Website. These data are available as letter-paper placeholders and are displayed on invoice PDFs, provided your letter paper references them. Once maintained, they appear automatically on every outgoing business document.

In the URL "Legal Notice & Data Protection" field, you enter the link to your legal notice and privacy policy. ZEP shows it on the login page.

Optional PayPal.Me name available as a letter-paper placeholder. This lets you enrich invoices with a direct payment prompt via PayPal.Me — recipients click the link and land directly in the PayPal payment form of your company. The field appears from ZEP Operations onwards, where invoicing is included.

Via the field Shareholders/Directors/Board you store the legally required information on the management — depending on your legal form. The information typically appears in the footer of invoices and business letters as soon as you use the corresponding letter-paper placeholder.

Mandatory for invoice output to business customers: VAT No. (European VAT identification number), Tax no. (national tax number of your tax office) and, if applicable, the Economic identification number (W-IdNr.). All three values flow into the ZUGFeRD metadata and are available as letter-paper placeholders.

Fields for Commercial Register number and Responsible registration court. Mandatory information for registered corporations and partnerships under German commercial law. Like the management, the values appear as letter-paper placeholders in the footer of outgoing business mail and invoices.

Fields Global identification number and Global identification number type. For the type, you choose between Global Location Number (GLN) and Data Universal Numbering System (DUNS). Required for B2B data exchange and for certain XRechnung profiles in which a unique company identification is mandated.

ZEP enters the SEPA Creditor Identifier into the machine-readable invoice formats as soon as payment by direct debit is marked for a customer. You obtain the ID from the first-time issuer, for Germany from the Deutsche Bundesbank. The field appears together with the machine-readable invoice formats. The BESR-Id is the Swiss payment-slip reference number for the Swiss QR code in Switzerland and only appears for country code CH.

When using the Departments module, you can store separate company data per department. Useful when departments act legally as separate companies or use different bank details for invoicing — ZEP automatically picks the matching data set based on the project's department assignment.

You maintain this data on the respective department: open the department and switch to the Other menu group, then open Department as company. Activate the option Use this data as sender. For step-by-step instructions, see the article Create and Manage Departments.

In the sub-menu Bank details, you store one or more bank details of your company. ZEP uses these data for ZUGFeRD and XRechnung invoices, for the payment QR code and as letter-paper placeholders. If a bank account changes (e.g. after a bank switch), maintain it here centrally — all letter-paper placeholders update automatically.

Per bank account, you maintain the following fields:

When several bank accounts are stored, you select the appropriate one per invoice. One bank account is prefilled automatically in new invoices: ZEP selects the bank account whose language and currency match the invoice (for departments, additionally based on the project department) — employees do not have to select it manually per document.

If Name in the company data and a complete bank account (Bank, IBAN, BIC) are stored, ZEP can output a payment QR code (also called GiroCode or EPC QR code) on invoices. The QR code contains recipient, IBAN, BIC, amount, currency and purpose — customers scan it in their banking app and save themselves the manual transfer of the data into the transfer form.

The code does not appear in the invoice PDF automatically. You activate it via the placeholder %R_BEZAHLCODE% in the upper or lower invoice text (project or customer additional fields). For right-aligned output, the placeholder can be embedded in a table cell with right alignment.

When using the Departments module, you can maintain separate bank accounts per department. Useful when departments act legally as separate companies and customers should transfer to different accounts. ZEP automatically picks the matching bank account based on the project's department assignment and outputs it in invoice, dunning letter and letter paper.

In the sub-menu Letter Paper, you upload your own letter paper with logo, address, bank details and mandatory information for business mail. All PDF, Word and LibreOffice reports of ZEP are output on this letter paper. Without your own letter paper, ZEP uses a neutral standard template with company name and page number in the footer.

You store a separate letter paper for each report area:

ZEP provides a step-by-step guide for creating the letter paper in LibreOffice. The guide and a template are available for download directly in the letter-paper area. Detailed instructions on document variables, page templates, paragraph templates and layout can be found as a deep dive in the separate Supplementary article: Create and upload letter paper.

You store separate templates per language and area. ZEP supports six languages: German, English, French, Spanish, Slovak and Turkish. Based on the project language, ZEP automatically selects the matching template. This way, invoices to international customers can be generated in the desired business language, without employees having to assign a template manually per invoice.

When using the Departments module, you can store separate letter papers per department — useful when departments appear under their own letterhead or act as separate legal entities. ZEP automatically picks the matching template based on the project's department assignment.

In the sub-menu Login, you control how employees log in to ZEP — classically by username and password, alternatively via OAuth (Google, Microsoft Azure, Keycloak, Okta, generic OAuth provider) or via LDAP directory service. The settings are spread across the tabs LDAP, OAuth and Other.

In the Other tab, you use the checkbox Use IP address authentication to restrict ZEP access to specific IP addresses — for example to the corporate network or the VPN gateway. Enter the permitted addresses separated by spaces. Logins outside this IP list are rejected, even if username and password are correct.

OAuth lets you set up Single Sign-On (SSO). In the OAuth tab, you select a provider in the OAuth Provider field and thereby activate sign-in via external identity providers. Employees then see an OAuth login button on the ZEP sign-in page and can authenticate with their Google account, Microsoft account, Keycloak account or a generic OAuth provider. ZEP matches the sign-in via the field with the provider ID, for example Google ID. You find it in the Employee File in the Edit Employee dialog, Master data tab. If the field is empty, ZEP compares the email address of the OAuth account with the one stored in ZEP.

Register ZEP as an app in the Google Cloud Console. You receive Client ID (Google: Client ID) and Client Secret (Google: client secret) and enter the glogin.php URL of your ZEP under the authorized redirect URIs. If the address of the Google account differs from the email address in ZEP, enter it for the person in the Google ID field. The sign-in starts via the link Sign in with Google on the ZEP login page.

In the Microsoft App Registration Portal (aka.ms/appregistrations) you register ZEP, store name and redirect URL and create a client secret under Certificates & Secrets. Enter the value in ZEP under Client Secret, the application ID under Client ID. For a restricted tenant, additionally the Tenant ID.

Complete procedure:

Further Microsoft documentation: docs.microsoft.com — Active Directory v2 Registration Portal.

Besides Google and Microsoft, ZEP also supports Keycloak, Okta and General as identity providers.

Per provider the following fields are maintained:

If signing in through the ID token fails, the message narrows down the cause. Login failed means that the provider returned no ID token or the configured claim is missing from it. Then check the scopes and the spelling under Identifier from claim. Employee '…' was not found shows the value from the token. Enter it for the person in the field with the provider's ID. A technical message such as ID token was issued by another issuer or ID token was issued for another client points to a mismatching ID token issuer or a wrong Client ID.

In the Other tab, you use the checkbox Lock normal ZEP Login to deactivate the username-password sign-in — useful when your organization exclusively uses OAuth or LDAP. When the lock is active, the multi-select list Who is allowed to unlock ZEP login via email? appears additionally. Enter here all administrators or a specific address list. These persons receive an unlock link via email when the lock is triggered and can re-enable the classical login if needed.

In the tab LDAP, you choose the sign-in method via the field Login via (- Without -, LDAP or LDAP (search)) and connect ZEP to an LDAP directory service. ZEP validates the access data against the LDAP server afterwards.

For classic LDAP, you maintain the following fields:

For LDAP (search), additionally maintain Hosts (space-separated), Port, Protocol Version, Bind DN, Bind Password and one or more Search DN entries. ZEP tests the connection before saving — on error, nothing is persisted.

In the sub-menu Password, you maintain quality criteria for the passwords used in ZEP. The settings apply to all employees who sign in classically by username and password.

You specify a Minimum length for the password (at least 3, at most 30 characters). The requirement is enforced when creating or changing a password — shorter passwords are rejected with a validation message.

Via the checkboxes under The password must contain at least the following characters, you activate the complexity requirements — individually selectable as one lowercase, one uppercase letter, one digit and one special character. Multiple checkboxes are cumulative. Employees must then cover all activated classes.

In the field Expiration days, you specify how many days a password is valid. After expiry, employees are prompted to set a new password on the next login. 0 means no expiry.

In the field Permitted failed attempts, you limit how often a wrong password entry is accepted before the account is locked for renewal. A reasonable default prevents brute-force attacks without immediately blocking legitimate typos.

If a user has forgotten their password or exceeded the permitted failed attempts, ZEP automatically offers a reset form on the login page. Username or email address is sufficient — ZEP sends a link for setting a new password to the email address stored in the employee profile.

Under Roles & Permissions you define what each role in ZEP may view, edit and evaluate. Every role comes with a default set of permissions that applies from the outset. This default is a starting point, not a fixed framework — you adjust every single permission per role to suit your organisation.

In addition to the fixed roles, you can create your own user roles as needed and put together their permissions yourself.

The User Roles tab contains the roles you assign directly to an employee: six fixed roles and your own user roles. Each role forms one column of the table.

By default, the fixed roles are ordered by the scope of their default permissions, from the most extensive role to the most restricted. As soon as you adjust permissions, that scope shifts, so there is no fixed ranking of roles. Depending on your configuration, a User may be allowed to do more than a Controller. Your custom user roles follow to the right of the fixed roles. You can change the order of the columns yourself, see Arranging columns.

If the fixed roles are not enough, you can create your own user roles in the User Roles tab, for example for administrative staff or for read-only access. Each custom role gets its own column in the table, and you assign it to employees just like a fixed role. You can create up to ten custom user roles.

You can create, rename and delete custom user roles if you hold the Edit permission in the Roles & Permissions row of the Administration area.

In the User Roles tab, click Create new role. If the table still contains unsaved changes, save or discard them first. In the Create new user role dialog, you fill in two fields:

Once created, the new role appears as a column with the copied permissions. If you select a custom role under Copy permissions from, you create a copy of that role.

You set the permissions of a custom role in its column just like for any other role and apply them with Save changes. All rows of the table are available.

In the header of each custom column, the three-dot menu opens the actions Edit and Delete. Under Edit, you change the name in the Edit role dialog. You adjust the permissions of the role directly in the table.

When you delete a role, ZEP asks for confirmation. If the role is assigned to employees, use the Alternative user role field to choose which role these employees receive instead, and confirm with Change assignment and delete role. You can choose the fixed role that the deleted role is based on and other custom roles with the same base.

Each person has exactly one user role, either a fixed or a custom one. With a custom role, they receive only the permissions from its column. The permissions of the fixed role that the custom role is based on are not added. A custom role can therefore also be allowed to do less than its template.

Contextual roles apply in addition. If a person with a custom role manages a department or a project, they also receive the permissions from the Department Manager or Project Manager tab there.

Unrestricted access remains reserved for the fixed Administrator role.

Each custom role is based on a fixed role. This is the role you selected under Copy permissions from when you created it. When you copy a custom role, the new role keeps its base. Without a template, the base is User. The base remains in place even if you later change the name or permissions of the role.

Which permissions from the table a person has is determined solely by the column of their custom role. In some places, however, ZEP does not check a single permission but which fixed role a person has. There, a person with a custom role counts as if they had the fixed role of its base. This mainly concerns:

Alongside the user roles there are four further tabs for roles that arise from an assignment: Department Manager, Project Manager, Customer Manager and Project Team Member. Anyone who heads a department, leads a project or is assigned to a project receives this role in addition to their user role.

The permissions in these tabs are the same as for the user roles. The only difference lies in their scope: they do not apply company-wide but to your own department including its subdepartments, your own projects or your own customers. Each tab only shows the areas relevant to that scope — the Project Team Member tab, for instance, only projects and tickets.

Two tabs contain two columns each, because budget responsibility changes the scope considerably: Project Manager and Project manager with budget as well as Customer Manager and Customer manager with budget.

The table arranges permissions in rows and roles in columns. Each row belongs to an area of ZEP — such as Employee, Projects, Customers, Tickets or Billings. A tick means that the role holds this permission.

Next to many row labels there is an info icon. Point at it with the mouse and a short text explains what the permission covers. This helps in particular with rows whose label combines several functions.

Within an area there are three kinds of rows:

If only some of the permissions in a collapsed group are set, the cell shows an intermediate state. Expand the group to see which individual permissions are set. Permissions that do not apply to a role appear without a check box.

You can move the role columns. When you point the mouse at a column header, a drag handle appears on its left side. Use it to drag the column to the position you want. Your browser remembers the order for your user account and the respective tab.

To change the width of a column, drag the right edge of its header. You can widen the column with the row labels the same way. The widths apply until you reload the page.

Each row can be granted in up to three access types. The table shows them as icon columns:

Evaluate is technically a viewing permission. ZEP shows it as a separate column because reports sit elsewhere in the menu than the data itself and are often meant to be granted differently. This way a role can evaluate an employee's project times without seeing their master data.

You set and remove permissions by clicking the check box in the corresponding row and column.

Permissions depend on each other. Anyone allowed to edit something must also be able to see it. When you set an edit permission, ZEP therefore adds the corresponding view permission automatically. Conversely, removing a permission affects the Full Access row of the area, because it is then no longer fully set.

Your selection is only applied with Save changes. ZEP confirms the save with a short message. The new permissions take effect immediately for all employees holding that role.

Warning: If you remove a permission, all employees with that role lose access as soon as you save. Check carefully for the User and User (Additional Permissions) roles which areas your employees need for their daily work.

The areas follow a consistent pattern. An area begins with the data that is visible on the object itself. The reports of that area follow. At the end come the actions, that is creating and deleting.

Two areas deviate from this pattern.

The Administration area covers the entire administration section with a single collective row. Individual parts are excluded from it and granted separately, because they are particularly far-reaching or tied to a module: Roles & Permissions, Month-End Closing, Receipt Inbox, ZEP License Management and Task Management.

The Roles & Permissions row controls access to this screen. With View you see the permission matrix, with Edit you can change and save it.

This area governs what employees may do for themselves, independently of their access to others. It covers My Receipts, My Absences, My Planning and My Work Items. Also here: the Attendance Status, that is whether a role may see the attendance indicator of the other employees, as well as the reports under My Reports.

The table only shows permissions for functions your instance holds. Areas whose module is not licensed do not appear. This concerns the areas Tickets, Departments, Offers, Billings and Suppliers. Individual rows within existing areas are also omitted when the related function is missing, for instance with receipts, work items, documents, resource planning or absences.

If a permission is missing, first check whether the related module is included in your licence. The Projects and Customers areas belong to project and customer management. Project and customer management is included in ZEP Track, ZEP Control, ZEP Operations, and ZEP Business.

In this screen you define what a role may do. Who holds which role is determined elsewhere:

Which roles you may assign depends on your own role. Administrators assign all roles. A System Administrator assigns all except Administrator. Department managers assign User and, provided they hold the corresponding employee permissions, also User (Additional Permissions).

Who may change the user role of a person is controlled by the Roles & Assignments row in the Employee area with the Edit permission. It takes effect through the user role or, for the employees of the managed department and its subdepartments, through the Department Manager tab. Without this permission, only User is available when you create an employee.

Only people who hold this permission company-wide through their user role can assign custom user roles. They are offered the custom roles whose base they may also assign as a fixed role. If someone already has a custom role, only a person with this permission can replace it. The selection lists the fixed user roles first, then the custom ones. Nobody can change the role of their own user account. In the employee list, the User role column also shows custom roles, and you can filter and sort by it.

Contextual roles are not granted through the User role field. They arise from the respective assignment: the department management on the department, the project management and project team membership through the function on the project, the customer responsibility on the customer record. Which ones exist and what they cover is described in the section Additional authorisations.

If someone sees less than you expect after assigning permissions, the cause is almost always one of four. Check them in this order, the first one costs the least time.

Department Manager, Project Manager, Customer Manager and Project Team Member are tied to a scope. Their permissions apply to their own department including its subdepartments, their own projects or their own customers. Some places in ZEP ask for a company-wide permission instead, because they can only offer everything or nothing.

This mainly affects two places that are asked about often: the option - Any - in the employee filter of a report, and the overview of current clock-ins. A department manager stays limited to their own departments there, even when holding the permission in their own tab.

The tab Project Manager holds two columns, and they are completely separate. A project manager without budget responsibility inherits nothing from the column with budget. In the default assignment the row Billings sits exclusively with the budget variant. That is why a project manager without budget responsibility can neither view nor edit invoices for their projects.

Which of the two variants someone holds is not decided by the permission matrix but by the field Function on the project team member. The options there are Project Team Member, Project Manager without budget responsibility and Project Manager with budget responsibility.

There are therefore two ways to the goal, depending on what is intended:

These rows are set more narrowly in the default assignment than many organisations need. They are listed here together with the place where you find them.

For read-only access, it is best to create a custom user role as described in the section Custom user roles. Under Copy permissions from, choose the option "No template (no permissions)" so that the role starts without permissions. You then build the read access through the access types, because View, Edit and Evaluate are separate permissions.

In the column of this role, set only View, and Evaluate where needed, in the areas concerned. Leave the column Edit empty. This holds, because the dependency works in one direction only: an edit permission pulls in the view permission, the reverse does not happen.

The basic settings from My Company take effect across the entire application. Important contact points: