16 August 2026
A meeting attendance report is only worth something if it can answer 'who was actually present, and for how long' under questioning months later. That means one row per join event, not one row per person, and identity fields that don't rely on whatever name someone typed into the client. Most attendance exports fail on both counts before anyone even opens the CSV.
Most calendar and video tools default to a one-row-per-attendee summary: name, total duration, done. That shape answers 'was this person in the meeting,' which is not the question a compliance review actually asks. The real question is usually narrower: was this person present when a specific decision was made, or during a specific disclosure, or for the full duration a training requires.
A single summary row can't answer that, because it collapses every join and leave into one number. Someone who was present for the first two minutes and the last three of a sixty-minute meeting shows the same 5-minute total as someone who left at minute 30 and rejoined for the last four. Both look identical on a per-person summary. They are not remotely the same for compliance purposes.
A record worth defending needs a join timestamp, a leave timestamp, and enough identity to tie the row to a real person rather than a session. Duration alone, without the two timestamps it was computed from, is a number someone has to trust rather than check.
Timezone matters more than people expect. A report generated in UTC and read by someone assuming local time can shift an attendance window by hours, which is enough to dispute whether someone was present for a required segment. Every timestamp needs its offset attached, not implied by a footer note about 'all times UTC' that gets lost when the file is forwarded.
People drop and rejoin constantly: a bad connection, a phone that switches from wifi to cellular, someone who closes a laptop lid by accident. Each of these produces a new session, and a report built for compliance has to keep every one of them as a separate row rather than merging them into a single continuous block.
Merging is tempting because it produces a cleaner-looking report, but it destroys the exact information a review needs — the gap. If someone was disconnected for the four minutes a decision was announced, a merged row that shows them present for the whole meeting is worse than no record at all, because it's confidently wrong. The fix is to log every session with its own join and leave time, and let whoever reads the report decide whether a two-minute gap matters for their purpose. AVAY's meeting record keeps sessions this way — a person who drops and rejoins shows as two rows, not one — because collapsing them is a decision the report shouldn't make on the reader's behalf.
A display name is chosen by the person joining, not verified by anything. Someone can join as 'Guest,' as a colleague's name, as a blank string, or as whatever was left over from a shared conference-room device from a prior call. Treating display name as the identity field in a compliance report means the report's central claim — who was here — rests on something the attendee controls.
The fix is to always carry an authenticated identifier alongside the display name: an account email, an SSO subject ID, or at minimum the dial-in number for phone participants. Keep the display name too, because it's useful context, but never let it stand alone as the row's identity.
Attendance reports get exported to CSV and opened in Excel or Sheets more often than they get read as raw data, and that's where a second, unrelated problem shows up. If a display name, meeting title, or any free-text field starts with an equals sign, a plus sign, a minus sign, or an at sign, spreadsheet software treats that cell as a formula rather than as text — this is CSV injection, and it's been a known issue since spreadsheets first learned to auto-detect formulas.
A display name like "=1+1" is harmless on its own, but a name crafted as "=HYPERLINK(...)" or a formula referencing external data can execute when the file is opened, sometimes leaking data or triggering a fetch to an outside URL. Nobody typed that name expecting an audit; the risk is that a hostile or careless participant sets their display name to something that becomes an active formula the moment a reviewer opens the export.
Any tool generating attendance CSVs for compliance needs to prefix ambiguous leading characters with a single quote or otherwise escape them before writing the cell, so text stays text. If you're building or reviewing an export pipeline, this is worth checking directly — open a generated CSV in a text editor, not a spreadsheet, and look at how a name like "=SUM(A1:A1)" would be written to the file.
Retention depends on what the meeting was for — a regulated training session, a board meeting, a client call under a specific contract — and that policy should be set before the report format is, not after. What's consistent across most compliance regimes is that the raw session log should be kept as the source of truth, with any summarized or rolled-up report generated from it rather than replacing it.
Keeping only the summary and discarding the session-level rows means a follow-up question — did this exact person see this exact segment — can't be answered later, even though the summary looked complete at the time.
| What it captures | What it can't answer | |
|---|---|---|
| One row per person (summary) | Total duration per attendee | Whether presence covered a specific segment or decision |
| One row per join event | Every session with its own join/leave time | Nothing — it's the source data everything else is built from |
| Display name as identity | A label the attendee chose | Whether that label maps to a real, verifiable person |
Keep UTC as the stored value but always attach the offset in the exported field so a reader isn't guessing. If the report is for a specific audience in one timezone, add a converted column rather than replacing the UTC timestamp — the original should stay traceable.
Keep the raw session log at least as long as your longest applicable retention requirement, and generate summaries from it on demand rather than storing only the summary. If the regulation or contract that governs the meeting specifies a retention period, that period should apply to the underlying sessions, not just the rolled-up report.
AVAY logs join and leave events per session rather than collapsing them into a single per-person total, and it carries authenticated participant identity alongside whatever display name someone set. It doesn't currently offer a dedicated compliance export format with built-in CSV-injection escaping — if you're pulling attendance data into a spreadsheet workflow, treat that export step as something to verify yourself.
When that value lands in a CSV cell and someone opens the file in Excel, Google Sheets, or LibreOffice Calc, the application may interpret it as a formula instead of text, executing whatever function is written there. This can range from harmless to genuinely risky — some formula patterns can trigger outbound requests or reference other data in the workbook. The mitigation is escaping on export, not on read, since by the time it's opened the damage path is already set.
Only after checking what shape it produces. Test whether reconnects show as separate rows or get merged, whether the identity field is the authenticated account or just the typed display name, and whether a formula-like display name comes through escaped in the CSV. Those three checks catch most of what makes an attendance export unusable for compliance.
An attendance report is only as good as its rows: one per join event, not per person, with an authenticated identity field alongside the display name, and text fields escaped before they hit a CSV — because a display name is not identity, and a cell starting with an equals sign is not text.
Meetings that take their own notes, in the browser: avay.ai.