Exhibitor Regulations for the 2026 Exhibition: Applications and Deadlines

A practical framework for working with the exhibitor regulations: a single register of requests, owners, dependencies, internal deadlines, confirmations and late changes.

The exhibitor regulations for a 2026 exhibition can run to dozens of pages. Forms sit in the exhibitor portal, rates arrive in a separate appendix, transport rules are published later, and clarifications remain in emails. If you simply hand the documents out to departments, the project will not get a shared plan. Each participant will have their own fragment and their own understanding of the word "done".

At Aventura, we translate the exhibition's exhibitor regulations into a single register of requests. It shows owners and input data. Dedicated fields show dependencies, deadlines, current status and confirmation.

Such a register does not replace the official documents. It shows which requirement has already been met, what is blocking the next step, and how to handle a late change without losing history.

The deadlines in this article cannot be applied to a specific exhibition without verification. Dates depend on the organiser, the venue, the type of stand, the services ordered and the current version of the documents. That is why there is no universal rule below like "all requests must be submitted 30 days in advance". There is a way to find the dates of a specific event and set internal checkpoints.

How do you turn an exhibitor's regulations into a working plan?

In short: turn the exhibition's exhibitor regulations into a working register. Gather the latest version of the manual, contractual appendices, personal account forms and the venue's technical rules. Put each requirement on its own line, add application card fields and assign an owner. The result is that the team gets a list of obligations with statuses and confirmations, rather than a retelling of the document.

Regulations usually mix several levels. The general participation procedure may be in the main section, the power supply form in an appendix, and transport requirements in a separate manual. Some requirements apply to all exhibitors, others only to custom-built stands, rigging, large exhibits or special work.

The first step is to identify the set of sources for the specific event. We request:

• the contract and the organiser's appendices;
• the exhibitor manual or handbook;
• the venue's technical regulations;
• access to the personal account and the services catalogue;
• forms for the stand design, electrics, rigging and other work;
• the procedure for passes, bringing in, removing and transport slots;
• requirements for advertising artwork and the catalogue;
• letters with changes that supplement the main document.

Each file must have a date received or a version number. A link "somewhere in the account" is not acceptable. If the organiser replaces a form or updates the transport scheme, the team must understand which version was used when submitting.

Next, the project team breaks the document down into actions. The phrase "the exhibitor must approve the design" turns into several lines: prepare the package, carry out an internal review, send it, receive comments, make corrections and keep written confirmation. A single line "stand approval" hides too many states and does not show where the work has stopped.

This is where the topic divides. Detailed accreditation of contractors and transport answers questions about people, vehicles, cargo and access. The exhibitor register only links this process to the exhibition requirement, deadline and confirmation. Similarly, the technical inspection of the finished structure itself relates to acceptance of the exhibition stand, not to submitting applications.

From a document to a single register

A single register is needed where an official document stops being a convenient tool for day-to-day control. It does not copy the entire text of the rules. It links a requirement to an action, a person, a date and proof of the result. Email, chat and the personal account remain the working channels, but the final status of each application returns to one table.

An ordinary calendar shows a date. It rarely explains which file needs to be prepared, who approves it and what will happen if it is delayed. Correspondence keeps the details, but does not give the overall state of the project. The register brings dates, tasks and decisions together in one place and keeps links to the source documents.

We start with an inventory. Each requirement gets its own identifier, for example STAND, POWER or SUSPENSION for an application to suspend structures. The coordinator marks up passes, logistics and printing in the same way.

The code is not there for the sake of bureaucracy. It links a line to a folder of documents, an email, an invoice and an entry in the personal account.

The review process looks like this:

1. Collect all official documents and note their versions.
2. Write out the names of applications, permits, forms and mandatory actions.
3. Break large items down into verifiable stages.
4. State the source of the requirement and a link to the relevant section.
5. Assign the owner of the result and the participants in the preparation.
6. Add the input data and dependent tasks.
7. Carry over the external deadline without rounding or guesswork.
8. Set an internal deadline allowing for review and corrections.
9. Determine which confirmation will close the line.
10. Check that the register covers installation and dismantling.

If one application combines several independent results, it is better to split it. For example, "logistics" may include a cargo letter, a transport slot, vehicle details, passes for people and the procedure for return removal. These elements change separately and receive different confirmations.

The overall event approval calendar covers the client's decisions, the programme, the venue and production. The exhibitor's register is narrower. When organising exhibitions and stands, we include in it the requirements of the organiser and the venue, as well as the internal actions without which the team will not meet those requirements.

What should a request card contain?

In short: a request card should answer nine questions: what is required and on what basis; who owns the result; what data is needed; what the submission depends on; when the external deadline falls; what internal deadline has been set; what is happening right now; and what confirms closure. If the answer is buried in an email thread, the line is not yet ready to be managed.

A minimal card starts with the request name and its source. The request owner states the source precisely: document, section, form, link or email with a date.

Next to it, the coordinator states applicability. For example, a requirement may apply only to individual construction, a two-storey structure, suspension, water connection or work outside the standard window.

The owner is responsible for the request's result and manages it through to closure. The executor may prepare a drawing, list or file. The approver reviews the material within the company. These roles must not be mixed into a single "responsible parties" field, otherwise no one understands who should return the project to work after a comment.

A working matrix might look like this:

This is a template, not a ready-made calendar. Form names, field sets, deadlines and evidence vary. Even the same service at two events may be processed through different accounts and follow a different approval route.

The team sets statuses in advance. We use only those values that change the next action. At the start, a request may be not started, awaiting input data, in preparation or under internal review. After submission it may receive comments, move to correction or await payment.

Final statuses: accepted, approved or cancelled. The word "in progress" is too broad and does not show who should act now.

Request owners and boundaries of responsibility

Every request must have a single owner who is responsible for it until the result is confirmed. They collect the input data, initiate the internal review, monitor the deadline, return comments to the contractor, and save the confirmation. Other participants may prepare files and approve decisions, but the overall status is updated by the assigned owner. This way the task does not get stuck between departments.

A common mistake is to assign a department as the owner. Wording such as "marketing", "developer" or "technical service" does not answer the question of who will check the line today and make the decision. The register needs a specific role, and the company's internal process needs a specific person.

We distinguish four functions:

• the result owner manages the request until closure;
• the input data provider prepares the information or file;
• the approver makes the decision within the company;
• the sender works with the official channel of the organiser or venue.

One person can perform several functions. But the transition between them must remain visible. For example, the developer prepares the rigging plan, the technical manager checks the loads, the client confirms the budget, and the coordinator submits the form. The request owner ensures that all four actions are completed before the internal deadline.

It is useful to add a deputy for critical lines. This is not a second owner. The deputy gets the right to continue the process in the absence of the main person and knows where the documents are kept. The project manager determines criticality by the consequences of a delay, not by how impressive the service name sounds.

For a complex project, we hold a short meeting on the register. The meeting participants do not read all the lines in a row. The team looks only at requests with an approaching internal deadline, open dependencies, comments and late changes. This format is faster than a long report and immediately shows where the client's decision is needed.

We publish practical case studies of exhibition projects in the Aventura Telegram channel. There we talk about venues and the work of the project team.

How to set internal deadlines without universal due dates?

In short: first, transfer the external deadline exactly from the document for the specific event. Then count backwards through the mandatory actions: collecting input data, internal approval, technical review, correcting comments, payment and uploading to the official channel. The owner sets the internal deadline so that the team has time to fix comments before the delay affects production, logistics or installation.

A universal buffer creates false confidence. Simply ordering furniture and approving a complex structure require different amounts of time. A layout may depend on translation and legal review.

A transport request depends on the vehicle, driver and cargo list. A rigging request is not ready without geometry and loads.

We build the internal deadline from the scope of work. To do this, the owner answers the questions:

• what data must arrive before preparation begins;
• who checks the result inside the company;
• is a specialist calculation or certificate required;
• can the venue return comments;
• is an invoice and payment confirmation required;
• will the request change production or logistics;
• at what point does correction become expensive or impossible.

After that, the owner links the deadline to the dependency. If the power supply is determined by the equipment list, the final supply cannot be scheduled before the consumers are fixed. But waiting for all materials to be fully ready is also risky. First, the scope and capacities can be confirmed, while secondary details are handled separately if the event rules allow it.

In the register, it is useful to keep three dates: the external deadline, the internal deadline and the date of the next action. The last one is needed for current work. A request may have a distant external deadline, but today a drawing is awaited from the contractor. Without a next action date, the line looks calm until there is no time left to correct anything.

If an official document gives a specific deadline, we apply it only to that event and that form. For example, overseas venues may request separate engineering packages several weeks before installation. Such examples confirm the need for early approval, but do not create a rule for another exhibition in Russia.

Dependencies between the project, services and access

An application rarely exists on its own: the stand design affects electrical work, rigging, fire safety documents and production. The equipment list affects power supply and passes for the technical team. Logistics depends on the cargo, the vehicle and the available window for a specific exhibition. That is why the register must show incoming and outgoing links.

Without these links, a row closed locally can leave the project unfinished.

The most useful part of the register is the "dependency" field. It answers two questions: what must be in place to close this application, and what cannot be started without it. This way the team can see which open tasks are holding up the next applications and the entire project.

The main links usually look like this:

• the stand geometry unlocks calculations, rigging, part of the electrical work and production;
• the equipment specification defines power, network, installation locations and the composition of the technical team;
• the selected materials are linked to supporting documents and venue rules;
• final layouts unlock printing, the catalogue and advertising placements;
• the list of contractors unlocks data collection for installation passes;
• the cargo inventory links the warehouse, the import letter, the vehicle and the return shipment;
• the transport slot depends on the event rules, the type of vehicle and cargo readiness;
• a paid service order may be a condition for its actual provision.

For technical equipment, we first compile a list of consumers. A socket on its own explains nothing. We need the equipment, the rated power per the documentation, the operating mode, the connection point, the switch-on time and the person responsible for switching it off.

If the project includes screens and sound, the event technical equipment service helps link this block. The specific scheme and tolerances are confirmed by specialists in line with the venue rules.

Rigging is especially sensitive to changes. A designer may move a sign, but for the register this means new geometry, a different point and a possible change in load. After such a change, the "approved" status cannot be left without checking whether the confirmation still applies.

The stand's operating scenario also affects applications, although it is not part of the regulations itself. The article "An exhibition stand as a funnel" helps define the demo, negotiation and contact-capture zones. The exhibitor's register then links the chosen scenario to electrical work, internet, furniture, passes and logistics.

How do you confirm that a request has been accepted?

In short: sending a file only completes the sender's action. The request owner verifies the result through an official channel: a number or status in the portal, an acknowledgement email, an invoice, or written approval. They save the link and the confirmation date in the register. That way another participant can check the current status without searching through someone else's inbox.

In other processes, the result is a payment confirmation, written approval, or an issued pass. In the register, keep the link to the confirmation and the date so that another participant can check the status without searching through someone else's inbox.

The statuses "sent", "received" and "approved" mean different things. After receiving the form, the organiser may still review it. An issued invoice does not confirm payment, and an initial review of the project may end with comments. Until the team receives a response against the defined criterion, it does not consider the request resolved.

A confirmation matrix helps agree on the criteria:

The confirmation must relate to the current version. If, after approval, the team replaced the plan, the list of people, or the vehicle, the old email may no longer close the line. In the card, the owner states the file version or the data set to which the decision relates.

We do not keep evidence only in one employee's inbox. The link leads to a shared project folder with clear access rights. The team stores personal data in a separate folder with restricted access. The team puts only the minimum necessary status into the shared register, without extra details.

Late changes without losing history

A confirmed line cannot be rewritten as if the previous version never existed: create a separate change record. State the reason, the affected requests, the decision owner and the new confirmations. Then assess the timeline, cost and technical consequences for the project. A change is closed only after all dependent lines have been re-checked.

Separately record the impact of the change on installation.

A late change does not always mean a mistake. An exhibit, vehicle, employee, mock-up or equipment list may change. The problem arises when the team corrects one table but does not review the related requests.

For each change we record:

• what was confirmed before the change;
• what exactly is changing;
• why the replacement arose;
• who authorised proceeding;
• which register lines are affected;
• whether re-approval is needed;
• whether the price, timeline or terms of performance change;
• what new confirmation is required;
• who communicates the decision to contractors and the installation team.

The late change route goes through several steps:

1. Stop using the old version in dependent tasks.
2. Create a change record without deleting the original status.
3. Identify all related requests and orders.
4. Obtain an assessment from the relevant participants.
5. Record the project owner's decision.
6. Submit corrections through the official channel.
7. Save the new confirmations and terms.
8. Pass the current version to all affected contractors.
9. Check the result before installation or departure.

Verbal approvals to "sort it out on site" are especially dangerous. If the venue allows a change, the team still records who confirmed it and to what extent. A verbal discussion can be used for a quick decision, but the team must obtain final written confirmation.

After the freeze point we do not automatically prohibit changes. We make them visible and assess the consequences.

Sometimes the right decision is to abandon a new feature in order to preserve the approved installation. Sometimes a change is critical and requires a new design. The decision depends on the specific exhibition and confirmation from the relevant specialists.

What to check before installation and departure?

In short: before departure, first check that the register is closed: critical requests must have up-to-date written confirmations. Open restrictions must be clear to the entire project team. The project team separately verifies people, the vehicle, the cargo and the planned works. The coordinator sends the latest version of the documents to everyone involved in the installation.

The team takes to the site only the current set of documents and contacts for prompt decision-making.

This check does not replace accreditation and acceptance of the finished stand. With its help, the project team makes sure it has received the documents, permits and confirmations to start work.

The control process can be carried out as follows:

1. Filter the rows that block installation, entry or the provision of services.
2. Check the versions of designs, lists, layouts and transport data.
3. Open each confirmation rather than relying on the status colour.
4. Verify payment for services if the contractor or venue will not start work without it.
5. Separate permits for people, transport, cargo and special works.
6. Check the entry route, the checkpoint, the window and the unloading area.
7. Give the driver and the contractor only up-to-date instructions.
8. Prepare a list of open restrictions and decision owners.
9. Make sure that return removal and dismantling are also entered in the register.
10. Appoint a channel for recording changes during installation.

On the transport side, you cannot limit yourself to the phrase "the pass has been issued". At certain events, the coordinator checks the driver, the passengers and the class or number of the vehicle. They also verify the window booking, the cargo list and the arrival point.

InnoTrans 2026 links entry to registration, the temporary window and correct vehicle data.

The installation team receives a short extract instead of the entire array of project files. It includes the necessary passes, confirmations of ordered services and contacts of the responsible roles. It also contains the arrival plan, open conditions and links to current documents. Personal and restricted data are shared only with those who need them for the task.

Specialists check the actual structure, finishing, routes and equipment later, during acceptance. Using the exhibitor register, the project team makes sure it has received the necessary documents, approvals and permits for installation in accordance with the rules of the specific event.

Closing the loop after dismantling

The exhibitor regulations remain in force after the exhibition opens: once dismantling is complete, the coordinator confirms removal, the return of rented property and the closure of services. The project manager then checks the handover of documents and the deletion of unnecessary personal data. Only after that do they close the register. The team keeps the useful templates and takeaways.

The team does not carry old deadlines over to the next event.

Dismantling is often handled less thoroughly than installation. The main forces have already switched to the exhibition results, while transport, returns and documents remain with a few contractors. That is why the reverse cycle needs to be entered in the register in advance, while the cargo composition and task owners are still clear.

At the final stage, the project manager checks:

• the letter and documents for return transport;
• the transport window and vehicle details;
• the return of rented furniture and equipment;
• the handover of the space according to the venue's rules;
• closing documents for the services ordered;
• the return of passes or media, if required;
• the status of damage and disputed items;
• the deadline for deleting temporary lists and document copies;
• the archive of current confirmations and decisions.

After the project, it is useful to review the register. The team flags requests that depended on late input data and confirmations that took too long to find. Separately, the project manager looks at which changes affected more rows than expected. These answers improve the template for the next project.

But the old register must not be turned into a ready-made calendar for a new exhibition. The team keeps the card structure, roles, typical dependencies and confirmation rules. For a new event, the team re-checks dates, forms, rates, accounts and requirements against the current documents.

At Aventura, we consider a good register complete when, for every critical row, we can quickly answer: who owned the result, on what basis the team acted, what was confirmed, which version became final and how the cycle closed after dismantling.

Sources

• Messe Frankfurt: Technical Guidelines, September 2025 edition
• Messe Berlin: Technical Guidelines, June 2019 edition
• InnoTrans 2026: Traffic Guide
• RAI Amsterdam: Facility Regulations
• RAI Amsterdam: Logistics
• Messe München: Logistics and Traffic