Who sees plate cost on a BEO, and who never does

A single BEO gets read by a lot of different people before a private event happens: the kitchen, the floor, the client, sometimes an outside planner. Not all of them see the same numbers on the page. A BEO is used by the kitchen, banquet captains, the catering manager, accounting, and front desk, among others — a lot of surfaces for one document to reach correctly.

The question worth asking is not whether to show cost to everyone or hide it from everyone. It is which audience gets which view, and whether that split is something the document enforces on its own, rather than something a person has to remember to do by hand each time a BEO goes out.

Who is actually allowed to see cost on a BEO?

Internal and kitchen views carry plate cost and margin; client and front-of-house views do not. In Excellent's document engine, a BEO renders for one of four audiences — client, kitchen, foh, or internal — and cost fields are written into the kitchen and internal renders only. The client and FOH renders strip those fields at the point the engine builds the page.

That means the same underlying BEO — same event, same menu, same run of show — produces more than one legitimate page, and each one is correct for who reads it. A line cook sees what a dish costs to plate. A server sees the dish, the timing, and the allergens, and nothing about what it cost to make. Neither is a trimmed copy typed up by hand; both come out of the same source document through the same render step.

Why strip cost at the render step instead of editing a copy afterward?

Because a system that keeps a cost version and a no-cost version as two separate files depends on someone remembering which one to send. Industry guidance on BEOs already draws this line in practice: an internal version carries operational cost detail the client never sees, and some workflows go further and produce a parallel document with no pricing at all for parties who should not see it. Excellent's engine draws the same line at the document's one source, at render time, rather than leaving it to a person copying and editing a version before every send.

What does a BEO's reach across departments have to do with cost?

A BEO is meant to be read by many different roles on one event — kitchen, banquet captains, catering manager, accounting, front desk — so the same document has to say different things to different readers without anyone editing it by hand for each one. That is exactly what the audience-scoped render is built to do: one artifact, rendered once per audience, with cost fields present only where the audience is kitchen or internal.

Does this replace the judgment behind who can change a BEO at all?

No. Audience-scoped rendering controls who sees which numbers on a given render; it says nothing about who can edit the document itself or sign off on a change once it is final. That is a separate question, covered in who signs off on a change to a finalized BEO.

The standard security posture for any system holding financial detail runs on the same principle in different words: give each role only the access its job requires, and restrict sensitive figures to the people who manage them. In restaurant point-of-sale environments specifically, keeping sales and cost reports restricted to management-level roles is treated as standard practice, not an afterthought. A BEO's audience split applies that same idea to one document instead of to a whole system of logins.

What this means in practice

A kitchen view and an internal view carry plate cost and margin. A client view and a floor view never do. The split is not something a person decides fresh for every event; it is built into how the document renders, so the version that goes to a guest or a server is never one edit away from showing a number it should not. You can see how this plays out across a whole event's document set on the private dining software for groups page.