Frequently asked questions about DBJOY

DBJOY is management software for study travel operators: companies that build and sell language holidays and study trips abroad, including school groups, individual enrolments on language courses, and a term or a year abroad. DBJOY covers the whole programme lifecycle inside one database, from the student’s enrolment to the final margin on the booking file.

Rather than covering a single stage, DBJOY keeps CRM, quoting, enrolments, partner schools and per-session allocations, students, travel documents, administration and reporting in the same place. Data is entered once: a confirmed quote becomes a booking file, the booking file produces vouchers, info sheets and rooming lists, and the same file feeds the invoice and the margin report.

DBJOY is designed around three profiles:

• study travel operators assembling course and accommodation with partner schools abroad, per-session allocations and a margin to defend session by session;
• schools and school group organisers working with accompanying teachers, school contacts and families;
• agents and consultants selling study programmes who need a tour operator back office.

DBJOY is built around Italian package-travel practice and Italian tax rules, rather than adapted from a product designed for another market.

See all nine DBJOY modules

A booking engine sells: it publishes availability and prices, takes the reservation and collects payment. Study travel software produces and administers the programme: it builds the quote on the partner school’s net rates, opens the booking file, tracks per-session allocations and accommodation, issues travel documents and closes with the invoice and the real margin.

The gap between the two product categories shows up in the work a booking engine, by design, usually does not cover:

• partner school contracts, per-session allocations and release dates;
• student records, registration fees and family instalment schedules;
• operational documents such as vouchers, info sheets and rooming lists;
• the VAT margin scheme for travel agents and electronic invoicing;
• margin by session, destination and salesperson, not only turnover.

A study travel operator that assembles course, accommodation, flight and transfer needs the back-office system. A booking engine, where one is used, is a sales channel that connects to that system rather than replacing it. The two categories answer different questions: a booking engine answers whether the customer can buy this now, while study travel software answers what the programme actually cost and what it actually earned.

How the DBJOY modules fit together

Neither product category is better in the abstract: a vertical study travel system and an international all-in-one travel suite solve different problems. A vertical system goes deep on how a study travel operator actually produces a programme, from the partner school contract to the host family match. An international suite goes wide on distribution, connectivity and running several markets from one platform.

For a company established in Italy, the practical question is where the expensive problem sits. Four areas usually need local work inside an international suite, because they come from Italian law:

• the VAT margin scheme under art. 74-ter of Presidential Decree 633/1972, Italy’s version of the EU special scheme for travel agents in Articles 306-310 of VAT Directive 2006/112/EC;
• electronic invoicing through the Italian SDI exchange system;
• the information obligations of the Italian Tourism Code (Legislative Decree 79/2011), which implements Directive (EU) 2015/2302;
• the accounting separation between services bought in from third parties and the operator’s own services.

An international suite can be stronger on global distribution and on multi-country deployment. DBJOY starts from the opposite premise: Italian package-travel practice, Italian tax rules and the study travel trade itself sit inside the data model, not in a module added afterwards.

VAT, invoicing and administration in DBJOY

Spreadsheets and a shared drive work while one person holds the whole picture in their head. They stop working when several people quote, enrol and invoice the same sessions, because the same figure then lives in several files and nobody can say which one is current.

A back-office system for study travel operators differs from a spreadsheet in three ways, and none of them is a feature list:

• one record of the truth: the confirmed quote becomes the booking file, and nothing is retyped;
• state that everyone can see: which partner school has confirmed, which release date is approaching, which family still owes a balance;
• figures that reconcile: supplier costs land on the booking file they belong to, so the margin is a calculation rather than an estimate.

DBJOY is built for the moment when a study travel operator has enough volume that parallel spreadsheets start disagreeing with each other. The cost of changing system is real, and most of it is the initial set-up on rates, partner schools and destinations. The three-month free trial exists so that an operator can test the change on its own data before deciding.

From quote to booking file, without retyping

DBJOY is used the same way by a small study travel operator and by a larger structure: what changes is how many modules are switched on and how many people work in them. A small operator does not need a dedicated IT function to run DBJOY, because DBJOY is a web application used from the browser.

For a small team the argument is usually the opposite of size. A company where two or three people do everything is exactly the company that cannot absorb double entry, a missed release date or a margin discovered at year end. Concentrating roles in a few people makes a single system more useful, not less.

What a small study travel operator should check before committing:

• which modules are genuinely needed on day one, and which can wait;
• how much of the initial set-up on rates, partner schools and destinations falls on the internal team;
• who inside the company owns the data once the system is live.

The three-month free trial is designed for exactly that assessment: DBJOY is configured on the operator’s real rates and partner schools, so the decision rests on the company’s own workload rather than on a demonstration.

How the three-month free trial works

DBJOY is built around Italian package-travel practice and Italian tax rules, so an operator established outside Italy should treat that as the starting point of the conversation rather than a detail. The operational core is not country-specific: quoting, booking files, partner schools, per-session allocations, students, rooming lists, travel documents and margin work the same way anywhere. The fiscal and documentary layer is another matter.

The parts shaped by Italian law are:

• the VAT margin scheme under art. 74-ter of Presidential Decree 633/1972, Italy’s implementation of the EU special scheme for travel agents (Articles 306-310, VAT Directive 2006/112/EC);
• electronic invoicing through the Italian SDI exchange system;
• the information obligations of the Italian Tourism Code (Legislative Decree 79/2011).

An operator in another EU country works under the same EU frameworks, the special scheme for travel agents and Directive (EU) 2015/2302, but through its own national implementation, its own invoicing channel and its own language requirements. A UK operator works under TOMS and outside the EU package travel regime.

DBJOY does not promise ready-made support for another country’s tax regime or invoicing channel. The honest route is to describe the country, the VAT treatment and the invoicing obligations, and to check the fit case by case before any commitment.

Describe your set-up and we will check the fit

A free trial of study travel software is a period in which a company uses the system on its own work instead of on a demonstration dataset. DBJOY offers a three-month free trial: long enough to run a real cycle, from quote to enrolment to departure to invoice, rather than a one-hour presentation.

The DBJOY trial is built on the operator’s own material:

• initial set-up done together on the operator’s real rates, partner schools and destinations;
• support alongside the team while the first quotes and enrolments go through;
• full use of the product for the three months;
• no automatic purchase commitment and no tacit renewal;
• data entered during the trial belongs to the operator and stays exportable.

Three months matters for a study travel operator because the work is seasonal and back-loaded. A trial that only covers quoting says nothing about what happens at departure, at final invoicing, or when a partner school cost arrives two weeks after the group came home. The point of the period is to reach the margin at the end of a real booking file, which is where a back-office system either earns its place or does not.

What the free trial includes

The DBJOY three-month free trial does not require a credit card and does not carry an automatic purchase commitment. There is no tacit renewal at the end of the period: continuing is an explicit decision, and doing nothing does not turn into a contract.

That structure is deliberate. A study travel operator evaluating a back-office system commits the team’s time far more than its money, and a trial that quietly becomes a subscription pushes the decision for the wrong reason.

What an operator should still get in writing before starting any trial, with any supplier:

• what happens to the data at the end of the trial, in what scope and within what window;
• whether the trial environment continues as the live environment or has to be rebuilt;
• who owns the initial configuration work if the operator does not continue;
• how the trial can be stopped early.

DBJOY answers those questions in the trial agreement rather than in marketing copy, so an operator can read the terms before the team invests three months of real work in the system.

Start the free trial on your own data

At the end of the three-month trial a study travel operator has three options: continue with DBJOY, stop, or ask for more time on a specific point that was not tested. Nothing happens automatically, because the DBJOY trial carries no tacit renewal and no automatic purchase commitment.

If the operator continues, the intention is that the environment used during the trial carries on with the data already entered and the configuration already done, so that the set-up work is not repeated from scratch.

If the operator stops, the data entered during the trial remains the operator’s own and stays exportable. Scope, format and the window in which the export is available are set out in the agreement rather than left to good will, and are worth reading before the trial starts rather than after it ends.

A useful way to close the three months is a short review against what the operator wanted to fix at the beginning: the step from quote to enrolment, the visibility of per-session allocations and release dates, the payment schedule of a group, and the margin on a completed booking file. A decision taken on those four points is a decision taken on evidence.

How the trial is set up and closed

DBJOY is quoted on request rather than sold from a single published price list, because the cost depends on how the company is shaped and on how much of the system is actually put to work. A single headline figure would not survive contact with two operators of different size and different scope.

The variables that shape a DBJOY quote are:

• how many people work in DBJOY, and in which roles;
• which modules are activated, for example the portal, integrations and reporting;
• the volumes handled, in booking files, sessions and enrolled students;
• the start-up work: initial configuration, data migration and training.

The fastest route to a figure is to describe how the company works today, including destinations, partner schools, the type of groups and sessions handled and the tools already in use, and to ask for a quote on that basis. The three-month free trial runs alongside that conversation, so the commercial decision arrives when an operator already knows what DBJOY does on its own data and over what perimeter.

Ask for a quote for your own set-up

Data migration into DBJOY is handled as part of the initial set-up rather than as a self-service upload, because study travel data is rarely clean: the same partner school appears three times, student records sit in a different file from payments, and historical booking files carry costs that arrived after the group came home.

The practical approach is to agree the perimeter before moving anything:

• master data first, meaning families and schools, partner schools and accommodation, destinations and rates, because everything else hangs off it;
• open booking files, which have to be usable from day one;
• historical files, where the real question is whether the operator needs them live in the system or as a consultable archive.

On the way out, the principle is that the data belongs to the study travel operator and stays exportable. Formats, scope and timing are the part to settle in writing rather than assume, and they are worth asking about before a migration starts. A back-office system holds the commercial history of the company, and an operator should be able to leave with it.

How the initial set-up and migration work

DBJOY treats a group as one booking file with many students attached, not as a series of individual bookings. Each student has a record: personal details, travel documents, room or host family allocation, dietary or medical requirements, and an individual payment position inside the group.

That structure is what makes the three recurring group problems manageable:

• the rooming list and the host family matching are built from the student records and their allocations, and change with them, instead of being kept as a separate spreadsheet emailed to the partner school;
• the payment schedule works per payer, with a registration fee and instalments carrying their own due dates, so an operator can see which family is up to date and which is behind without adding up bank transfers by hand;
• the guaranteed departure threshold is a number watched against confirmed enrolments, not an estimate rebuilt from emails.

A group also changes constantly: a student withdraws, a host family match is swapped, a partner school cost moves. DBJOY is designed so that a change is made once on the booking file and reaches the rooming list, the student list and the payment position from there, instead of being applied three times in three documents.

Students, groups and enrolments in DBJOY

DBJOY holds an allocation as a contracted quantity against a partner school or an accommodation provider and a date range, with sales drawn from it as enrolments are confirmed. At any moment an operator can see how many course places and beds were contracted, how many are sold and how many are still free, per supplier and per session.

The release date is the part that costs money when it is missed. In DBJOY the release date is a property of the allocation rather than a note in somebody’s calendar, so unsold places carry a deadline and an owner.

Around that, a study travel operator normally needs to distinguish three situations:

• allocation: course places, host family beds or residence rooms held under contract, sellable until the release date without asking;
• on-request: places to be confirmed by the partner school case by case;
• option: a hold with an expiry, which either becomes a confirmation or lapses.

Booking files created from an allocation carry the supplier cost with them, so the same movement that reduces availability also feeds the cost side of the margin. How far the release itself is automated is a configuration point to confirm against the operator’s own partner school contracts during set-up.

Partner schools, accommodation and release dates

DBJOY builds the quote on net supplier costs — course, accommodation, flight, transfer, student insurance — and shows the mark-up while the quote is being composed, not afterwards. Gross price, mark-up and resulting margin are visible at the moment the commercial decision is made, which is the only moment at which they can still be changed.

The real margin, however, is not the quoted margin. It is what remains once every supplier cost has actually landed on the booking file, including the ones that arrive after departure: a late partner school invoice, an extra week of tuition, a free place for an accompanying teacher, an exchange difference on a foreign supplier.

DBJOY is designed so that costs are attributed to the booking file they belong to, which lets an operator compare:

• the margin expected when the quote was confirmed;
• the margin realised when the booking file is closed;
• the difference, read by booking file, destination, partner school and salesperson.

Turnover tells an operator how busy the company was. Margin by booking file tells the operator which sessions are worth repeating and which partner school contracts are worth renegotiating. DBJOY is built to answer the second question, which is the one that is hardest to reconstruct from spreadsheets.

Reading real margin, not just turnover

A study travel operator buys in the currency of the destination and usually sells in euro: a partner school in the United Kingdom invoices in pounds, one in the United States in dollars, so the exchange rate sits between the quoted margin and the realised one. DBJOY is designed to record supplier costs in the currency they were agreed in and to carry them through to the booking file, rather than flattening them into a single converted figure at the moment of entry.

That matters because three different rates can touch the same programme:

• the rate used when the quote was built;
• the rate at which the supplier invoice is actually settled;
• the rate used for accounting purposes.

Keeping the original currency on the cost line is what later allows an operator to see whether a destination lost margin on the programme itself or on the exchange. Which rate sources are used, how often they are updated and how differences are posted to the accounts are configuration questions to settle with the operator’s accountant during set-up, because they follow the company’s accounting policy rather than the software.

Partner school costs, rates and contracts

In DBJOY, travel documents are generated from data already held in the booking file rather than assembled by copying and pasting. The voucher, the info sheet, the rooming list and the student list all read from the same student and supplier records, so a change made once reaches every document that uses it.

That difference shows up under pressure, in the week before departure, when a rooming list changes twice and a host family is swapped. Documents rebuilt by hand are where a misspelt name, a missing allergy or an outdated host family address reaches a partner school.

The documents a group departure normally needs are:

• the voucher for each supplier service;
• the info sheet with times, meeting points and emergency contacts;
• the rooming list and host family allocations sent to the partner school;
• the student list for transport and for the group leader.

Templates, layout and which documents are produced for which type of service are part of the initial configuration, set up on the operator’s own document set rather than on a generic default. A document that a partner school already recognises is worth more than a tidier one it has never seen.

Travel documents generated from the booking file

DBJOY is built on the VAT margin scheme that applies to travel agents and tour operators. Under Articles 306-310 of VAT Directive 2006/112/EC, an operator selling packages in its own name is taxed not on the whole price but on its margin: the difference between what the traveller pays and the cost of services bought in from other taxable persons for the traveller’s direct benefit. VAT charged on those bought-in services is not deductible.

Italy implements that scheme in art. 74-ter of Presidential Decree 633/1972. English-speaking readers usually know the equivalent as TOMS, the Tour Operators Margin Scheme, which is how the United Kingdom runs the same margin principle under its own rules outside the EU VAT system.

Whichever name applies, the margin is only calculable if the underlying data is right:

• supplier costs attributed to the correct booking file, including those arriving after the group came home;
• services bought in from third parties kept separate from the operator’s own services, which are taxed differently;
• sales documents carrying the correct VAT nature code, N5 for margin scheme operations in Italian electronic invoicing.

DBJOY keeps the booking file register with revenue and costs per file and carries those figures through to the invoice and the accounts. The exact scope of the automatic calculations is verified against the company’s accounting set-up with its accountant, because the scheme leaves choices to the operator.

Administration, VAT and invoicing in DBJOY

DBJOY separates services bought in from third parties from services the study travel operator supplies itself because the two are taxed differently. Under the special scheme for travel agents in Articles 306-310 of VAT Directive 2006/112/EC, and under art. 74-ter of Presidential Decree 633/1972 in Italy, only services acquired from other taxable persons for the traveller’s direct benefit reduce the taxable margin.

A service the operator provides with its own means falls outside that calculation and follows ordinary VAT treatment. Typical examples are the operator’s own coach, its own group leader or tutor on site, or teaching staff employed directly on a language course.

The consequence is practical rather than theoretical. If the two categories are mixed on the same booking file, the margin figure is wrong and so is the invoice, and the error is discovered at the worst possible moment. DBJOY is designed so the distinction is made where the cost is entered, on the service line, instead of being reconstructed at the end of the quarter. How a specific operator’s own services are classified is a decision taken with its accountant during the initial set-up.

How costs are classified for VAT

Electronic invoicing in Italy runs through the SDI, the exchange system operated by the Italian Revenue Agency: an invoice is not issued when it is printed but when it has passed through SDI. DBJOY is designed so the invoice is built from data already held in the booking file, covering the family or school being invoiced, services, amounts and VAT treatment, rather than retyped into a separate invoicing tool.

For a study travel operator the specific point is the VAT nature code. Operations under the margin scheme of art. 74-ter of Presidential Decree 633/1972 are reported with nature code N5, which means VAT is not shown separately on the invoice. Getting that wrong is not a formatting problem, it is an incorrect filing.

Around the invoice itself an operator still has to settle:

• which system is the system of record for tax documents;
• who handles transmission to SDI and the delivery notices that come back;
• how compliant long-term storage is arranged;
• how sales documents reach the accounting system.

The exact division of work between DBJOY, the accounting package and whoever handles SDI transmission is defined during set-up with the operator’s administration and accountant.

From booking file to electronic invoice

Directive (EU) 2015/2302 on package travel and linked travel arrangements, applicable across the EU since July 2018 and implemented in Italy through the Tourism Code (Legislative Decree 79/2011, as amended by Legislative Decree 62/2018), places specific duties on the organiser: pre-contractual information delivered on a standard information form, a package travel contract on a durable medium, information on price revision and withdrawal, and protection against insolvency.

Software does not take on those duties. Responsibility stays with the organiser selling the trip. What a system can change is whether the required information is generated from the booking file and travels with the quote and the sales document, instead of being an attachment somebody has to remember every time.

The documents that normally accompany a package booking file are:

• pre-contractual information and the standard information form, delivered with the proposal;
• the package travel contract, linked to the booking file, the student and whoever signs it;
• terms on withdrawal, price revision and organiser liability;
• details of the mandatory insolvency guarantee and of any insurance cover.

The wording of those documents remains the organiser’s responsibility, defined with its own legal adviser. DBJOY is there to attach them reliably to the document flow of the booking file. A revision of the directive was adopted in 2026 and takes effect only once Member States have transposed it, so the obligations that apply today remain those of the national implementation currently in force.

Contract documents attached to the booking file

On a study trip the participant is usually a minor, so this is the normal case rather than the exception: student details, travel document, allergies, intolerances or ongoing treatment, consents and authorisations signed by whoever holds parental responsibility, and the contacts to use in an emergency. DBJOY treats these as data requiring extra care, and access is limited to the users who genuinely need them to organise the programme.

The lawful basis under Article 6 GDPR is normally the performance of the contract with the party that signed it, meaning the school or the family, rather than consent to marketing. Information on allergies, intolerances or ongoing treatment needs further care: it is required to deliver the programme safely — to the host family, to the partner school canteen, to the tutor on site — and it should travel no further than that.

The operating principles that follow are:

• collect only the data the programme requires, not everything a school or a family could supply;
• restrict access by role inside the organisation;
• share with partner schools and host families only the minimum needed, for example the rooming list and dietary requirements;
• keep the data for the period defined by the controller, then delete it;
• handle data subject requests under Articles 15-22 GDPR.

The tour operator remains the data controller for its own processing, alongside the school for the part that falls to the school. The software supplier acts as processor under Article 28 GDPR, on the controller’s documented instructions.

How DBJOY protects student data

DBJOY is a web application: a study travel operator’s data lives on server infrastructure reached from the browser, not on individual office computers. Inside the company, access is governed by named user accounts and role-based permissions, so each person sees the booking files and the figures their role requires and not the rest.

Two questions matter more than any general reassurance, and an operator should have both answered in the contract rather than on a web page:

• in which country the infrastructure hosting the data is located;
• which sub-processors are involved, since Article 28 GDPR requires them to be disclosed and authorised.

On the supplier side, the software supplier acts as processor under Article 28 GDPR and works on the controller’s documented instructions. The tour operator remains the data controller for its families’ and students’ data.

Day-to-day access control also stays with the tour operator: revoking accounts when someone leaves, limiting who can see cost and margin figures, and deciding who is allowed to export data. DBJOY is built to make those decisions configurable rather than to assume one flat level of access for the whole company.

Data, access control and processing roles

Backups and service continuity are contractual facts rather than marketing claims, so DBJOY does not publish figures that would supposedly apply to every configuration. What a study travel operator should obtain in writing, from any software supplier, is a short and specific list.

The questions worth asking are:

• how often backups are taken, and where the copies are held;
• how long copies are retained, and whether restoring a single booking file is possible or only a full restore;
• the target time to restore service after an incident, and the target for how much data could be lost;
• how planned maintenance is scheduled, and whether it avoids the operator’s peak weeks;
• how an incident is communicated, to whom, and how quickly.

For a study travel operator the timing dimension is the one most often underestimated. An interruption in a quiet week is an inconvenience. The same interruption in the days before a group departure, when vouchers and rooming lists have to reach partner schools and families, is an operational problem with a cost. Continuity commitments are worth reading against the company’s own calendar rather than against an annual average.

Data protection and continuity commitments

DBJOY is designed to be the back office of the study travel operator, not the only system in the company: accounting, the public website and its online enrolment form, payment tools and email typically stay where they are and exchange data with DBJOY. The integration most operators ask about first is accounting, together with the sales documents that feed it.

Before building anything, two decisions do more work than the technology:

• which system is the source of truth for each entity, meaning families and schools, sales documents and supplier costs, so the same figure is not maintained twice;
• which direction each flow runs, and how often it runs.

What typically crosses the boundary is sales documents, supplier costs attributed to booking files, and the elements needed for the margin calculation under art. 74-ter of Presidential Decree 633/1972.

Whether a specific integration exists as a standard connection, as an interface or as a project is checked case by case on the systems actually in use, together with the operator’s administration and accountant. Access to any interface is granted per connected system and per permission scope, not as a general opening of the database.

How DBJOY connects to the systems you already use

DBJOY support is organised around a study travel operator’s calendar rather than an abstract office schedule. The peaks land in the enrolment months and in the weeks before the summer sessions depart, and that is exactly when a blocked booking file cannot wait until Monday.

DBJOY does not publish a single response time in hours, because a number without context is not a commitment: service levels belong in the contract. The right question to put to any software supplier is contractual rather than general:

• which contact channels exist, and during which hours;
• how requests are classified by severity, separating an operational blockage from a configuration request;
• what response and resolution targets apply to each class;
• whether there is a named contact who already knows the company’s configuration;
• how coverage changes during peak periods.

Those answers are worth getting in writing and testing against the part of the year when the company works hardest, not against an annual average. An operator that evaluates support during a quiet week in November has not really evaluated support.

Talk to us about your season and your team