Introduction

XTM offers a robust costs module that technically covers the whole scope of the project translation process in our application. Since it is quite extensive and allows for applying varied configurations (as well as takes into account different cases), depending on clients' needs, let’s focus on those aspects that are essential for the costs module to work at all.

Getting started

Billing currency & Exchange rates

The adventure with XTM costs should be commenced in Configuration → Data → Estimates → Exchange rates (administrative privileges required!).

• System billing currency → This is one of the first things we need to set up in the XTM instance. Linguists in XTM to whom we will be allocating translation tasks may want to be paid in different currencies, so it is necessary to establish a proper billing currency that XTM will use to calculate costs in accordance with an exchange rate.

• Rate card currency → In case linguists have different currency in their rate cards (more on them in the later part of this article), this is the section where you need to find out what currencies your linguists are going to use, add appropriate rate card currencies and, in the Billing currency section, fill in the field with a proper exchange rate. If you do not specify a certain currency that is in use, costs for that particular user will fail to generate.

Chargeable workflow steps

You need to specify workflow step(s) that should be chargeable in your project by selecting the appropriate checkbox. However, first of all, you need to activate such a possibility in Configuration → Data → Estimates → Cost settings → Cost settings → Show Chargeable checkbox in Workflow Editor.

Rate cards

XTM has a highly flexible rate card function that supports billing in a defined currency. Those rate cards are yet another prerequisites for the future generating of costs. Therefore, our next step is to configure rate cards for active users. This is done in Users → (select a user) → Rate cards.

• User billing currency → This is where you choose a currency in which a given user will be remunerated.

Click the Add button to create a rate card.

For each rate card you can define:

• The name to identify the rate card;

• A description of the pricing and usage for the rate card;

• Whether the rate card is active or not;

• One or more language combinations – either single languages or groups;

• One or more subject matters.

Then you can define how the cost of the task will be calculated. It can either be based on factors or actual prices. You can also set whether the calculation should be by word or character. If you choose factors, you must enter a base price which will be multiplied by the percentage values you enter for the different types of match in each step, to work out the cost. If you use actual prices, then you should enter the actual prices for each type of match for each step. For both types of calculation, you can also define:

• A minimum charge

Under the General fixed price heading you can set:

• A fixed price per project;

• A fixed price per language;

• A fixed price per file;

• A management fee percentage

Then for each workflow step you can define:

• A fixed price project;

• A fixed price language;

• A fixed price file;

• A management fee percentage;

• Rush job premium – A rush job premium percentage;

• Minimum charge;

• Price per hour;

• The rates for fuzzy matching factors or actual prices can be set as a global figure or individual figures for each band.

After creating a project…

Once the project is created, you need to check a couple of additional things:

• Make sure the relevant linguists are assigned to their tasks in the workflow:

• Make sure the workflow step that is subject to payment has the checkbox Chargeable enabled:

• Finally, go to Project editor → Estimates → Costs, and choose the basis for your costs by selecting the relevant option in the Generate costs based on drop-down:

If you chose Metrics or Current metrics, you are good to go with generating costs. Statistics source and target, on the other hand, require prior manual work on the project from your linguists.

Costs calculation mechanism

Procedure

For each workflow step (in a given target language) for a given user:

1. Metrics/Statistics/Timing is taken (and from there words or character, depending on the calculation method applied).

2. Values from 1 are multiplied by rates from rate card matches ((unless charging by time is used).

3. To the resulting value from 2 management fee is added, later - fixed rate.

• If the value is too low, it is increased up to minimum charge (fixed price per each task).

4. The resulting value from 3 is saved in database.

5. For each target language “costs per workflow step” are summed up.

6. To the resulting value from 5 management fee is added, later - fixed rate.

• If the value is too low, it is increased up to minimum charge (fixed price per project).

7. The resulting value from 6 is saved in database:

8. For each user “costs per language” are summed up.

9. To the resulting value from 8 management fee is added, later - fixed rate.

• If the value is too low, it is increased up to minimum charge (fixed price per project).

10. The resulting value from 9 is saved in database:

11. For each project “costs per user” are summed up.

12. The resulting value from 11 is saved in database:

Example

For simplification: All the matches have the value equal to 1, each workflow step consists of 10 translated words.

1. Rate cards

Fixed prices per project: Man. fee 10%, Fixed price 10, Min charge 115.

• RateCard1 - pl_PL:
  Fixed prices per language: Man fee 25%, Fixed price 5, Min. charge 55;

  • Fixed prices per Translate: Man fee 20%, Fixed price 5, Min. charge 15;

  • Fixed prices per Correct: Man fee 10%, Fixed price 3, Min. charge 15.

• RateCard2 - de_DE:
  Fixed prices per language: Man fee 50%, Fixed price 15, Min charge 40;

  • Fixed prices per Translate: Man fee 10%, Fixed price 2, Min charge 10.

2. Costs calculation

• pl_PL:

  • Translate:
    10 * 1,2 + 5 = 17 → 17 > 15, so the final price for this step amounts to 17.

  • Correct:
    10 * 1,1 + 3 = 14 → 14 < 15, so the final price for this step amounts to 15.

Total price for steps: 17 + 15 = 32

32 * 1,25 + 5 = 45 → 45 < 55, so the total price for language amounts to 55.

• de_DE:

  • Translate:
    10 * 1,3 + 7 = 20 → 20 = 20, so the final price for this step amounts to 20.

Total price for steps: 20

20 * 1,5 + 15 = 45 → 45 > 40, so the total price for language amounts to 45.

3. Final result

• Sum for the languages: 45 + 55 = 100;

• Price for the user: 100 * 1,1 + 10 = 120 → 120 > 115, so the final price for the user amounts to 120;

• Price for the project (the sum of costs for all users): 120.

After costs are generated…

Costs tab

Once you click the Generate button, all the costs that are generated will appear in the already mentioned Costs tab in the form of a UI record (Project editor → Estimates → Costs).

As you can see, you have got a couple of basic information pieces about the entry such as:

• Date of generating the costs;

• User who generated costs (the costs may as well be generated automatically);

• Basis for generated costs;

• Aggregated price;

• Delivery date (if specified beforehand);

• Total number of words;

• Total number of existing ICE/Leveraged matches.

As you may have spotted, costs are generated for the whole project. In order to see a breakdown per linguist, we need to click on the entry. You will see more details.

• Linguists' names for whom costs have been generated;

• Purchase Order number;

• The Price column shows the linguist’s remuneration in your system billing currency;

• Both costs for non-analyzable files and additional costs can be specified as either a fixed amount or as a percentage of the base price;

• Linguist price shows the remuneration in the linguist’s rate card currency that is displayed in a Purchase Order;

• Workflow steps, as the name suggests, shows steps' names in which a given linguist was involved and which are within the payment scope.

• Email status tells whether an e-mail with PO was sent off to the client or not.

Purchase Order

You can generate a Purchase Order for each linguist.

• Generate PO → a default PO will be downloaded;

• Generate custom PO → a popup will open where you can choose the PO file format, calculation method, and custom fields. You can decide to include rates or a cost breakdown into languages or languages and workflow steps. Also, you can specify whether the PO should be automatically emailed to the linguist, add a comment, and customize the footer and font sizes. You can also set up a custom PO layout to be applied globally in Configuration → Data → Estimates → PO settings → Default PO.

• Email PO to linguist → You can send a PO to the linguist straight away. The sending status will be marked in the relevant column on the right-hand side.

XTM cost-related reports

XTM offers multiple reports pertaining to costs that can be generated and downloaded from the UI. The most important rule here is that the costs need to be effortlessly generated in order for the data from their corresponding projects to be displayed in such a report. In other words, the correctly generated costs is a must for the correctness of any XTM cost-related report. In order to see more details, please get familiar with the following article: Costs & Metrics reports.

Troubleshooting cost generation issues

There might be several reasons that prevent you from being able to generate costs properly. Please, see a separate article that tackles the most frequent problems with costs generation: Costs generation - most common issues & troubleshooting.

Phase costs and Statistics

To begin with, it should be noted that Statistics are modified only as a result of any manual activities of a linguist in Workbench. Contrary to metrics, Statistics are not modified after performing actions such as project re-analysis, continuous project update, or uploading new source files. Only the activity of a linguist in Workbench after the completion of the above-mentioned actions will modify Statistics.

Furthermore, very important are the settings under (administrative privileges required!)

Configuration → Data → Estimates → Cost settings → Automation of continuous projects → Save history of project metrics, statistics, tracked time and costs when.

These options decide whether those actions (reanalysis, continuous project update) and finishing pre-processing will result in resetting Statistics and generating phase costs.

• Project is reanalyzed → Creates a record of project costs data when an existing project is reanalyzed;

• Pre-processing is finished → Creates a record of project costs data when the pre-processing workflow step is finished;

• Source file with name existing in project is uploaded → Creates a record of project costs data when a new source file is uploaded to XTM and has the same name as any file already existing in the project.

In other words, selecting these options and reanalyzing/uploading files to a continuous project (CP) results in deleting Statistics from the UI. This mechanism is used so that after making the mentioned actions, the data in Statistics does not accumulate.

In this case, you can automate the cost calculation process by selecting the appropriate option in Generate costs for project history. In this case, every time you reanalyze/upload the file to a continuous project, costs will be generated first, and then Statistics will be deleted.

Option 1 - resetting Statistics disabled

Reanalysis - example

1. The client created a simple project with 1 step and 1 file (a .txt file) containing 10 segments.

2. None of the segments received a TM match, and the linguist translated all the segments.

3. The project was reanalyzed. Previously translated segments got ICE matches. Statistics remain unchanged.

4. The linguist changed the translation in each segment.

Continuous project update - example

1. The client created a simple project with 1 step and 1 file (a .txt file) containing 10 segments.

2. As in the previous case, none of the segments received a TM match, and the linguist translated all the segments.

3. The client made a continuous project update (modified the said .txt file - added 5 new segments, which gives the total number of 15 segments). Previously translated segments got ICE matches (except for one which got a Leveraged match). Statistics remain unchanged.

4. The linguist translated ONLY new segments (11-15) and approved the segment 10 (Leveraged match).

5. The linguist corrected the translation of the old segments (1-10).

Option 2 - resetting Statistics enabled

Reanalysis - example

1. The client created a simple project with 1 step and 1 file (a .txt file) containing 10 segments.

2. None of the segments received a TM match, and the linguist translated all the segments.

3. The client reanalyzed the project. Previously translated segments got ICE matches. Statistics are reset. From now on they are only available from the Statistics history level (Project editor → Statistics → Statistics history).

4. The linguist changed the translation in each segment.

Continuous project update - example

1. The client created a simple project with 1 step and 1 file (a .txt file) containing 10 segments.

2. None of the segments received a TM match, and the linguist translated all the segments.

3. The client made a continuous project update (modified the said .txt file - added 5 new segments, which gives the total number of 15 segments). Previously translated segments got ICE matches (except for one which got a Leveraged match). Statistics are reset. From now on they are only available from the Statistics history level.

4. The linguist translated ONLY new segments (11-15) and approved segment 10.

5. The linguist corrected the translation of the old segments (1-10).