Yes, an external bookkeeper can have reporting-only access if the software offers a role with the right report permissions and separate restrictions on editing. Do not assume that a role called “viewer” or “accountant” has that exact scope. Ask the vendor to show what the user can open, export and change on the accounts and devices your restaurant actually uses.
The owner should approve the access decision, with the bookkeeper defining the reports needed to do the work. The question matters before you sign, add a new integration or invite an outside firm: a broad administrator login may solve an export problem while giving someone unnecessary control over live operations.
Start with the bookkeeper’s actual workflow
List the routine tasks the bookkeeper performs, how often they perform them and which locations are involved. For example, they may need a monthly export of marketplace activity, a POS sales report and a record of adjustments. Ask which fields and date ranges they need, not just which report names they recognize.
Then separate access to information from authority to make changes. Reading an order record may be necessary for reconciliation; changing its status, total or items is a different permission. A bookkeeper may also need to export a report without being able to edit a menu, change integration settings or invite another user.
Decide who owns each part of the process:
- Owner or authorized manager: approves the scope, sends or authorizes the invitation, and removes access when the engagement ends.
- Bookkeeper: identifies required reports and checks whether the exported fields are usable.
- Vendor support: explains the available roles and helps demonstrate the setup, without becoming the default administrator of the restaurant’s account.
Use a named account for each person where the system allows it. Ask whether invitations expire, whether the owner can see active users, and whether access can be limited by location. Shared credentials make it harder to determine who accessed a report or made a change.
Check report coverage and read-only scope together
A restricted login is useful only if it reaches the information your bookkeeper needs. Review each source separately: direct orders, marketplace orders, in-store POS activity and any other channel in the engagement. The integration directory distinguishes live connections from those available on request, so confirm the status and setup for your locations rather than treating a directory listing as a promise of report access.
Ask the vendor to demonstrate the route from source to report. Is the information available in the integration dashboard, the restaurant POS, a separate marketplace account or an export? A connection that sends orders into a system does not, by itself, establish which financial fields an outside user can retrieve.
For every required report, check the locations, dates and channels included. Ask whether the export contains the fields your bookkeeper needs to distinguish sales, adjustments, fees and payouts. A payout is not the same measure as a sales total, and a processing fee is not a complete operating cost. Your bookkeeper should confirm that the fields support the intended reconciliation.
Also check where the role works. Can the bookkeeper use a browser from their own office, or is a restaurant device required? If the owner uses a tablet for daily operations, ask whether the same restrictions apply there and whether the bookkeeper needs access to that device at all. Check the export format and whether historical periods remain available after an integration changes.
Record gaps plainly. If a channel is outside the requested scope, mark it as excluded. If a required field or location cannot be demonstrated, mark it unknown until someone follows up. A limited role that misses half the required sources is not a complete solution; neither is a complete report obtained only through unrestricted editing rights.
Test allowed and denied actions
Agree on expected results before the demonstration. The following is a hypothetical example for one restaurant location: the owner wants a bookkeeper to export a monthly integration report but not change menus or orders. Support is present only to help with a controlled demonstration. These are acceptance criteria, not claims about any product’s available roles.
| Person | Action | Expected result | Follow-up if different |
|---|---|---|---|
| Owner | Invite and remove the named bookkeeper | Allowed after owner approval | Identify who controls invitations and removal |
| Bookkeeper | Open and export the required monthly report | Allowed for the agreed location and channels | Check report scope or agree on a manual export |
| Bookkeeper | Edit a menu item or order | Denied | Do not approve the role as reporting-only; ask about narrower permissions |
| Support | Help demonstrate access | Only the access authorized for the session | Confirm how support access is granted and ended |
The table sets out what each person should be able to do. During the demonstration, record the observed result separately from that expectation, along with the date, account role, device and person responsible for follow-up. A missing demonstration is an unknown, not a pass.
For the report check, have the bookkeeper sign in with their own proposed role and open the required date range. Inspect the export with the bookkeeper: does it contain the agreed channels and fields? Have the owner confirm that it excludes locations outside the engagement if location restrictions are required.
For denied actions, use a vendor-provided demonstration or sandbox account and sample data. Ask the bookkeeper to try to open the menu editing controls and order editing controls. Record whether each action is blocked, not merely whether the edit button is hidden. Do not attempt an edit on a live order to prove the restriction.
If order flow is also part of the purchase decision, run a separate simulated check with a unique test identifier. Match one source order to the POS or kitchen result, including modifiers and totals, and check supported exception handling. The simulation must not create a real card charge, guest message or courier dispatch. It is not a live service pilot and does not prove how the system will perform during service.
Finally, have the owner remove the test user and ask the former user to try signing in again. Check whether previously downloaded files remain with that user; removing account access does not retrieve a file already exported. Agree on how the bookkeeper will handle retained files as part of the engagement.
Decide on gaps, exceptions and removal
Turn the results into a short decision record. A pass means the demonstrated result meets the agreed criterion. A fail means it does not—for example, the proposed bookkeeper role can edit an order. Unknown means the required result was not demonstrated, such as an export for a location not yet connected.
For each fail or unknown, name an owner, a follow-up date and an acceptable next step. If the report cannot be accessed directly but the owner can export it, a manual handoff may be workable for a low-frequency task. Specify who runs it, when it is due and how the bookkeeper receives it. That workaround adds staff work and creates a dependency; it should not be described as direct bookkeeper access.
Do not grant an administrator role simply to close a reporting gap without an explicit decision. If broader access is being considered, the owner should approve the exception, specify its purpose and end date, and decide what controls and retest are needed. Ask a qualified adviser about contract or legal questions where appropriate.
Before signing or rollout, confirm who can invite users, how quickly an account can be disabled, whether support access needs separate approval and what happens when the outside engagement ends. Revisit the permissions when the bookkeeper changes, a location is added or a new integration changes the reporting workflow. The broader guide to direct integrations and middleware can help frame the connection choice; this access check remains necessary whichever route you consider.
Next step: Bring your report list and the permission table to a Fleksa restaurant management software demo. Ask the vendor to show the bookkeeper’s allowed export, the denied menu and order actions, and how the owner removes access for your proposed setup.
Frequently asked questions
Does read-only access always include exports?
No. Ask the vendor to demonstrate both opening and exporting each required report. A role may be able to view information without having the export or location access your bookkeeper needs.
Should the bookkeeper use the owner’s login?
Prefer a named account with the narrowest suitable permissions, if available. The owner’s login may carry editing and user-management rights that the bookkeeper does not need.
What if a required report is unavailable to the bookkeeper role?
Ask whether a narrower role can be configured or whether an owner-run export is practical. Record the gap, who will perform any manual handoff and when the team will retest it.
