A client dinner request lands in your inbox an hour before the booking. The question is not whether you can say yes. It is whether you can show, later, why you did.
What a gifts and hospitality register is for
A gifts and hospitality register records what was offered, who decided, and why, so a reviewer can reconstruct the decision without asking you.
The register is not a diary of pleasant evenings. It is the file that turns a private judgment into a documented one. A hamper arrives at year end, a supplier offers seats at a match, a partner proposes dinner during a review. Someone has to decide whether accepting is appropriate and whether it could read as an attempt to influence a decision. The register is where that judgment becomes visible to anyone who was not in the room.
A register that only lists items is a list. A register that captures the reasoning behind each entry is evidence. The difference shows up when a reviewer samples a few entries and asks why one dinner was approved and another was declined.
A policy that forbids each offer avoids the conversation and pushes the decision into the shadows, where nobody records it. A policy that allows judgment keeps the decision in the open, and the register is where that openness is stored. The entries are the record that the policy is being applied rather than recited.
The register answers two questions that arrive at different times. One comes from inside the team, when someone is unsure whether an offer is acceptable and wants to see how similar cases were handled. The other comes from outside, when a reviewer or a customer asks how hospitality is managed. A register built for the outside question sometimes answers the inside one as well.
Who decides whether a gift or dinner can be approved
Approval sits with a named person who owns the outcome, not with whoever happens to be nearest the request.
The approver is commonly a manager, a compliance lead, or a small panel, and the choice turns on how the offer could be read rather than on its size. A bottle of wine from a long-standing partner reads differently from the same bottle arriving during a live tender. The approver needs the context around the offer, not only the item.
The working test is whether the approver could explain the decision to someone outside the team without discomfort. If they could not, the request needs a more senior decision, not a quieter one. Naming the approver in advance also removes the pull to approve first and justify later.
Escalation is easier to run when the levels are set by role rather than by price. A first-line manager handles the ordinary case, a compliance lead takes the ones with any hint of a conflict, and a senior owner takes anything that touches a live deal. The register records which level the decision reached, so the pattern of escalations is visible over time.
The fields that make a gift record defensible
A defensible entry captures the offer, the business reason, the decision, and the name behind it, so the reasoning travels with the record.
| Field | What it answers |
|---|---|
| Offer | What was offered, described plainly |
| Counterparty | Who offered it, and the relationship behind it |
| Business context | Why the interaction took place |
| Decision | Accepted, declined, or approved with conditions |
| Decision owner | The named person accountable for the outcome |
| Date of decision | When the judgment was made |
The counterparty line matters more than it looks. An entry that cannot be tied to a business relationship is an isolated event. When that relationship later comes under review, the entries linked to it become the record that shows how hospitality was handled over time.
Describe the offer in plain language and resist the urge to dress it up. "Dinner with a client contact after a project review" is a more useful line than a coded label that only the requester understands. The entry is written for a reader who was not there, and plain description is what makes it readable a year later.
Consistency matters as much as the fields themselves. A register where one row reads "dinner" and another reads "client entertainment, fourth quarter, three attendees" is harder to review than one built on a shared structure. Comparable entries make patterns easier to read. The standard a working paper meets when someone outside the team opens it applies here, which is why audit working papers are a useful model.
The approval decision is the control
The decision to approve or decline is where a policy becomes real. Like any internal control, the register only preserves the decision if the owner and reasoning are visible.
Two teams can run the same policy and reach different outcomes. One weighs each offer on its merits, records the reasoning, and moves on. The other files a form after the evening has passed. Only the first holds up under scrutiny, because the second has records with no decisions inside them.
The harder cases surface at the approval moment. An offer that is unremarkable on its own can change meaning when the counterparty is bidding for work or when a decision involving them is pending. Writing that tension into the entry is more useful than resolving it quietly. A note that says the relationship predates the tender, and that no decision was pending, tells a reviewer far more than a bare approval.
The entry also protects the approver. A decision made in good faith and written down is far easier to stand behind than one rebuilt from memory under questioning. When the same counterparty appears again, the earlier reasoning becomes the starting point rather than a blank page.
What hospitality records should show
A strong hospitality record shows the decision trail: what was offered, who decided, on what basis, and whether entries for the same counterparty read consistently.
| Record question | What answers it |
|---|---|
| How did this offer reach the register? | The offer entry and its date |
| Who made the call? | The named decision owner |
| What informed the call? | The business context and any conflict check |
| What was the outcome? | The decision and any conditions attached |
| Does the pattern hold? | Entries for the same counterparty read together |
A register may be sampled rather than read end to end. A small set of entries can shape how the program is understood, so a thin sample with clear reasoning beats a complete register that reads like a log. Whether the team reports against customer expectations or an internal code of conduct, the register answers the same question.
Two qualities separate a register that survives a review from one that invites further questions: completeness of the fields and candor in the reasoning. A tidy set of entries that all read the same way can look consistent and still miss the hard cases, which is exactly what a careful reviewer probes.
The reviewer may also ask for the policy that set the expectation, the delegation that names the approver, and the path for escalating an unusual case. Keep those documents current and easy to reach, so a question about one entry does not turn into a hunt for the rules behind it.
Declined requests and conditional approvals
A declined request is not a failure. It is evidence that the review process engaged with a hard case.
A register that holds only accepted items tells a reviewer one of two things: nothing was declined, or nothing was recorded. Neither reads well. Logging the declined dinner, with the reason attached, shows the process working rather than idling.
Conditional approvals deserve the same care. When hospitality is approved on the understanding that the counterparty is not in a live procurement, that condition belongs in the entry. The condition belongs in the record because it can be lost if it is only spoken.
Declined entries also build the muscle for the next decision. When someone can point to a clear precedent, the conversation about an offer becomes quicker and less personal. The register turns a repeated debate into a lookup.
Keeping the register useful between reviews
A register stays useful when entries are written close to the decision and revisited on a routine, so gaps surface before a reviewer finds them.
Gaps appear when entries are rebuilt months later from memory and receipts. The person who made the call is the best source of the reasoning, and their memory fades faster than the paperwork. Write the entry while the decision is fresh.
A periodic read catches the drift that single entries hide. A counterparty that keeps appearing, a category of hospitality that has slowly become routine, an approver signing off on their own team's requests. None of those stand out in one row, and each one matters when the pattern is the question. The evidence hierarchy is a useful frame: an entry that carries a decision, a name, and a date stays load-bearing longer than one that captures only a receipt.
Hand the register to a person who did not make the entries and ask them to explain a sample. Where they hesitate, the entry is missing context rather than the reader missing knowledge. That reading test is more honest than a completeness check, because it measures whether the record stands on its own.
FAQ
Who should approve a gift or a client dinner?
The person who owns the relationship decision and can be named later. That is sometimes a manager, with the compliance lead holding the calls that could be read as influence. What matters is that the approver is named in advance and recorded in the entry.
What do we record when hospitality is declined?
Record it the way an accepted offer is recorded: what was offered, who raised it, the context, the decision, and the reason. A declined entry with a reason shows the process engaging with judgment instead of defaulting to yes.
Can an approval be given verbally?
It can, and it still needs to be written down. A verbal approval that does not reach the register is invisible to a reviewer, which makes it indistinguishable from no review. Log the decision and the name behind it while the conversation is fresh.
What if the approver is the person who would receive the gift?
That arrangement invites a second name. Route the request to someone outside the line so the decision is not reviewed by the person it benefits. The register shows the split, because a reviewer may ask how the conflict was handled.
Where CASK fits
A hospitality decision is easy to lose, because its pieces live in different places: the request in an inbox, the context in a conversation, the approval in a reply.
Keeping the records behind your decisions together is the practice CASK supports. The workspace keeps the request, the counterparty, the business context, and the decision beside the register entry, stored locally on your machine and run with your own model keys. Teams draft the entry, attach what supports the call, and route it for approval before the record is filed.
CASK does not decide whether a gift is appropriate, and it does not set your approval authority. Those calls stay with your people, and the workspace shows who made each one. CASK by Truvara keeps the reasoning attached to the record it explains, so the next question about a client dinner starts from the entry rather than from memory. Try CASK now and see how a hospitality register reads when each entry carries its own reason.