Title: Allow agents to select the date for time accounting
What is your original issue/pain point you want to solve?
We have users who “forget to write their time” because they do something in between their normal hours and thus need to update the correct time on the correct date
Which are one or two concrete situations where this problem hurts the most?
Agent worked on a ticket quickly on Monday, and the week after they find time to update the ticket, and need to write their time. The current configuration is that the time will be on the week after, and not on that day.
Agent fixed something but due to time-limitations is unable to finish updating the ticket, and needs to do it the day after, time should still be written on the day it was actually done. Maybe someway to link the comments and time.
Why is it not solvable with the Zammad standard?
I have not found any way to have a date field added in the hour registration. This is also a value that needs to be sent to our back-end time registration, where dates do matter for hours per day worked.
What is your expectation/what do you want to achieve?
Allowing time to be registered retroactively, allowing older dates to be set to write time.
Your Zammad environment:
Average concurrent agent count: 5 concurrent, ~30 weekly
Average tickets a day: 6
What roles/people are involved: Agents (service desk employees)
Anything else which you think is useful to understand your use case:
Depending on whether it can be somehow linked to a commend, it might be useful to show both the registered time and the date it should’ve been spent.
Thank you in advance, if I missed certain things that I can already do this please let me know, but I was unable to find it in the documentation, nor online.
Until something like this exists, here is how it works today, plus a stopgap. Per the admin docs, the time accounting dialog only appears when an agent updates a ticket together with an article, and the Activity list under Manage > Time Accounting > Accounted Time shows each entry with its “Created at” time. None of the columns the docs list is a separate work date, so a late entry shows up on the day it is typed.
A workaround for the back-end export:
1. Enable Activity Types and add one such as “Late entry”, so retroactive bookings are flagged in the Activity list.
2. Ask agents to start the internal note that goes with the booking with the real work date, e.g. “Worked 2026-10-12”.
3. Download the Activity CSV for the month (or pull it via the API). It gives you the ticket number, agent, time units, activity type and “Created at”, but not the note text, so for rows typed “Late entry” open the ticket (or read its articles through the API, which should also work) to take the real date before sending the figures to your time system.
It’s manual, but it keeps the per-day totals correct until a proper date picker is added, so this feature request is still worth voting for.
Thanks, however, since we need to use this field as public comments, we don’t want to add the specific dates in there, making it hard for us to add the date in front to make the hours, also since there is a workflow connected to our time-writing, pushing it to our hour registration (ERP) system.
Hopefully we can somehow implement this, since adjusting dates on the ERP system apparently isn’t an option for us internally (writing on older dates is, but we can’t adjust it), making time registration hard to implement in combination right now.
Thanks, that clarifies it. Some Zammad-only options, given the comment must stay public and the ERP can’t correct dates later:
Put the date somewhere other than the public comment. The admin docs say time can be booked on an article of any type, so agents could book the time on a separate internal note that carries the work date, keeping the public comment clean. Your workflow would then need to read that note, which may not suit it.
Add a Date field as a custom ticket attribute (Admin > Objects). Per the docs, objects are tickets, users, organizations and groups, not time entries, so it holds one value per ticket and the next booking would likely overwrite it. Workable only if your ERP push reads it at the moment of each booking.
Carry it to the ERP. The time accounting API returns ticket_article_id, time_unit, type_id and created_at, but no work date. The docs’ example webhook payload includes the ticket attributes, the article and a ticket_time_accounting list, so a trigger-fired webhook could send the date field alongside the booking. The docs say a trigger’s context is always the last added article, and the example doesn’t show what a time accounting entry looks like in the payload, so I’d test that first.
Since nothing native stores a per-entry date, voting for this request and adding your ERP constraint here is probably the most useful long-term step.