デフォルトでは、GT.Mは文字列の添字を、Unicode数値コードポイント（ $ASCII() ）値のデフォルトの順序でソートします。この暗黙の順序付けは、特定のアプリケーションに対して言語的または文化的に正しいかもしれないし正しくないかもしれないので、Unicode照合アルゴリズム（UCA）などのアルゴリズムの実装が必要になる場合があります。GT.Mでの照合の実装には、f(x) と g(y) という2つの関数の実装が必要であることに注意してください。f(x) は、バイトの各入力シーケンスを格納用の代替バイトのシーケンスに変換します。GT.Mデータベース・エンジン内では、Mノードは、それらが格納されているバイト順に従って検索されます。f(x) によって生成され得る各 y について、g(y) はオリジナルのバイト列を提供する逆関数です； つまり、アプリケーションが処理するすべての x について、g(f(x)) は x と等しくなければなりません。例えば、日本では、 例えば libiconv ライブラリを使用して、 UTF-8からJIS（日本工業規格）、JIS2012標準に変換することが適切な場合があります。次の要件が重要です：
明白な変換ルーチン ：変換とその逆変換は、各入力文字列を記憶のための一意のバイト列に変換し、オリジナルの文字列に戻された各バイト列を変換する必要があります。
添字内のすべての期待される文字順序の照合順序 ：GT.Mは、照合ルーチンへ(から)渡される添字文字列を検証しません。アプリケーション設計で不正なUTF-8文字シーケンスをデータベースに格納できる場合、照合関数はこれらを適切に変換して逆変換する必要があります。
変換前と変換後の異なる文字列の長さを処理する：入力文字列と変換された文字列の長さが異なり、ローカル変数の場合、GT.Mで渡された出力バッファが十分でない場合は、以下の手順に従います：
グローバル照合ルーチン ：変換されたキーは、最大キーサイズ構成または1019バイト（GDSキーの最大サイズ）の小さい方を超えてはいけません。GT.Mは、出力文字列記述子（タイプDSC_K_DTYPE_Tの）に1019バイトのサイズの一時バッファを割り当て、変換されたキーを返すよう照合ルーチンに渡します。
ローカル照合ルーチン：GT.Mは、入力文字列のサイズに基づいて出力文字列記述子に一時バッファを割り当てます。変換と逆変換の両方でバッファサイズをチェックする必要があります。十分でない場合、変換は十分なメモリを割り当て、出力ディスクリプタ値（ディスクリプタのvalフィールド）を新しいメモリを指すように設定し、変換されたキーを正常に返さなければなりません。GT.M はキーを出力記述子からその内部構造にコピーするので、照合ルーチンが戻った後でも割り当てられたメモリが残って利用可能であることが重要です。照合ルーチンは一般的にプロセスのライフタイム全体を通して呼び出されるため、したがって、GT.Mは、照合ライブラリがアプリケーション内のすべてのキーサイズを保持するのに十分な大きなスタティック・バッファを定義することを期待しています。あるいは、照合変換では、大きなヒープ・バッファ（システムの malloc() または GT.M の gtm_malloc() によって割り当てられる）を使用できます。アプリケーション開発者は、ニーズに最も適した方法を選択する必要があります。