Create & Configure TOD Templates

A Test of Details (TOD) template defines how Moby will match documents, extract data, and validate results. Good templates can be reused across similar engagements, saving hours of setup time.

What is a TOD Template?

Think of a template as a recipe for your test:

Test sample configuration — Which columns from your Excel matter?
Document categories — What types of supporting documents do you expect?
Matching instructions — How should Moby link documents to transactions?
Extraction models — What data should Moby pull from each document?
Validation rules — When should Moby flag an exception?

Once you create a template, you can reuse it for similar tests — just swap in a new test sample and supporting documents.

Template Components at a Glance

┌──────────────────────────────────────────────────────────────────┐
│                         TOD TEMPLATE                             │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────────┐    ┌──────────────────────┐               │
│  │ Reference Config │    │ Document Categories  │               │
│  │                  │    │                      │               │
│  │ • ID column      │    │ • Sales Invoices     │               │
│  │ • Match columns  │    │ • Purchase Orders    │               │
│  │ • Display cols   │    │ • Delivery Notes     │               │
│  └──────────────────┘    │ • Remittance Advice  │               │
│                          │ • Bank Statements    │               │
│                          └──────────────────────┘               │
│                                                                  │
│  ┌──────────────────┐    ┌──────────────────────┐               │
│  │ Matching         │    │ Extraction Models    │               │
│  │ Instructions     │    │                      │               │
│  │                  │    │ Per category:        │               │
│  │ "Match by        │    │ • Fields             │               │
│  │  invoice #,      │    │ • Descriptions       │               │
│  │  PO #, amount…"  │    │                      │               │
│  └──────────────────┘    └──────────────────────┘               │
│                                                                  │
│  ┌───────────────────────────────────────────────┐              │
│  │ Validation Rules                               │              │
│  │ • Chronological sequence (Order < Delivery…)   │              │
│  │ • Amount consistency across documents          │              │
│  │ • Cut-off / period checks                      │              │
│  └───────────────────────────────────────────────┘              │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Step-by-Step: Creating a Template

Step 1: Name and Describe Your Template

Give your template a clear, descriptive name:

Good names:

"Revenue Recognition — Full Document Chain"
"AP Vouching — Purchase Invoices"
"Payroll Testing — Payslips to Ledger"

Avoid:

"Test 1"
"Invoice test"
"My template"

Add a description explaining:

What type of audit test this supports
What document types are expected
Any specific assumptions or requirements

Step 2: Configure Test Sample Columns

Your test sample is the Excel file containing transactions to test. Tell Moby which columns matter:

Column Type	Purpose	Example
Transaction ID	Unique identifier for each row	Row number, Transaction ID, Journal Entry #
Matching fields	Used to find the right document	Invoice #, Vendor Name, Amount, Date
Display columns	Shown in results for context	Description, Account Code, Period

Auto-detection

Moby recognizes common column names automatically. If your headers are non-standard (e.g., "Inv#" instead of "Invoice Number"), you can manually map them.

Test sample best practices:

Headers in row 1
No merged cells
One transaction per row
Consistent date and number formats

Step 3: Define Document Categories

Document categories represent the types of supporting evidence you expect. Each transaction might need one or more document types.

For each category, specify:

Setting	Description
Category name	What type of document (e.g., "Sales Invoice", "Delivery Note")
Required or Optional	Must every transaction have this document?
Matching instructions	How to match this specific document type
Extraction model	What data to extract from this document type

Example: Revenue recognition testing might have:

Category	Required?	Purpose
Sales Invoice (Facture)	✅ Yes	Primary evidence — the invoice itself
Purchase Order (Bon de commande)	❌ Optional	Confirms the order was placed before delivery
Delivery Note (Bon de livraison)	✅ Yes	Proves goods were delivered — determines recognition period
Remittance Advice (Détail de règlement)	❌ Optional	Bridge document — links invoice to bank payment
Proof of Payment (Preuve de paiement)	❌ Optional	Final evidence that money actually moved

Step 4: Write Matching Instructions

Matching instructions tell Moby how to find the right document for each transaction.

For detailed guidance and examples, see Writing Matching Instructions.

Key principles:

Name the fields to match on (invoice #, amount, date, vendor)
Specify tolerance for dates and amounts
Mention variations in terminology
Indicate which fields are most important

Step 5: Attach Extraction Models

Each document category needs an extraction model that defines what data to pull.

Your options:

Select existing model — Choose from your library
Create new model — Build fields from scratch
Generate with AI — Let Moby suggest fields based on sample documents

For detailed guidance on building effective extraction models, see Create & Refine Extraction Models.

Step 6: Set Validation Rules

Validation rules automatically flag potential issues by comparing extracted values to your test sample.

Rule Type	Example	What it Catches
Amount tolerance	Flag if difference > 1%	Invoice amount doesn't match recorded amount
Date tolerance	Flag if difference > 7 days	Dates don't align (possible timing issue)
Required fields	Flag if Invoice # is empty	Missing critical data
Custom rules	Flag if delivery date > period end	Cut-off issues

Complete Example: Revenue Recognition Testing

Let's walk through creating a template for revenue recognition testing — one of the most comprehensive audit procedures, tracing the full transaction lifecycle from order to cash collection.

The Audit Objective

Revenue recognition testing verifies that revenue is properly recorded by tracing the full document chain: from customer order, through delivery and invoicing, to payment.

What we need to verify:

A purchase order was placed (the customer ordered something)
A delivery note proves goods were delivered before the period end
A sales invoice was issued and matches the recorded amount
A remittance advice links the invoice to a specific payment
A bank statement proves money actually moved

Assertions tested: cut-off (delivery before period end), accuracy (amounts match across all documents), and occurrence (payment confirms the transaction happened).

How the Documents Chain Together

Each document in the chain links to the next through shared identifiers:

Reference (GL/FEC)
       │
       ▼
  Sales Invoice ──────► Purchase Order      (linked by PO # on invoice)
       │
       ├─────────────► Delivery Note        (linked by BL # on invoice)
       │
       ▼
  Remittance Advice ──► Proof of Payment    (linked by payment amount)
  (Détail de règlement)  (Bank Statement)
       │
       ├── references Invoice # (links BACK to invoice)
       └── contains payment amount (links FORWARD to bank statement)

The Payment Verification Chain

The Remittance Advice (Détail de règlement) is a bridge document. Without it, there is no way to prove which bank transaction paid which invoice.

Invoice  ◄──  Remittance Advice  ──►  Bank Statement
              (bridges the two)

The remittance advice says: "We are paying Invoice #X for amount Y"
The bank statement shows: "Amount Y was credited on date Z"
Together they prove: the right invoice was paid, for the right amount, and money actually moved.

The Test Sample

Your test sample is a GL/FEC extract of sales transactions near year-end.

Sample structure:

Row	Libellé (Customer)	Numéro de pièce	Date de pièce	Montant HT	Compte comptable
1	Dupont SA	FA-2024-1847	28-Dec-2024	45 000,00	701000
2	Martin & Fils	FA-2024-1852	30-Dec-2024	12 500,00	701000
3	Leroy Industries	FA-2024-1855	31-Dec-2024	78 200,00	701000

Column configuration:

Column	Role in Template
Row	Transaction ID (unique identifier)
Numéro de pièce (Document Number)	Primary matching field — this is the invoice number in the ledger
Libellé (Customer Name)	Secondary matching field + display
Date de pièce (Document Date)	Matching + validation (compare to delivery and payment dates)
Montant HT (Net Amount excl. tax)	Matching + validation (cross-checked against invoice, PO, remittance)
Compte comptable (Account Code)	Display only

Document Categories Setup

Category	Required?	Purpose	How It Links
Sales Invoice (Facture)	✅ Yes	Primary evidence — the invoice itself	Matched to reference by invoice number (Numéro de pièce)
Purchase Order (Bon de commande)	❌ Optional	Confirms the customer ordered before delivery	Linked via PO number referenced on the invoice
Delivery Note (Bon de livraison)	✅ Yes	Proves goods were delivered — determines recognition period	Linked via BL number referenced on the invoice
Remittance Advice (Détail de règlement)	❌ Optional	Bridge: connects invoice to bank payment	References invoice number (back-link) + contains payment amount (forward-link)
Proof of Payment (Preuve de paiement)	❌ Optional	Final cash collection evidence	Matched via payment amount from the remittance advice

Flexible Combinations

You don't have to use all 5 document types. This test supports three levels:

Minimum (2 docs): Invoice + Delivery Note — verifies delivery vs invoicing
Three-way match (3 docs): Invoice + Purchase Order + Delivery Note
Full cycle (5 docs): All five documents — complete revenue recognition chain

Matching Instructions

For Sales Invoices:

Match sales invoices to reference transactions using the invoice number.

Primary match: Invoice number must match the reference "Numéro de pièce"
(exact match, ignore formatting differences like "FA-" vs "INV-").

Fallback if invoice number not found:
- Customer name (fuzzy match against reference "Libellé")
  + Net amount (within 1% of reference "Montant HT")
  + Invoice date (within 3 days of reference "Date de pièce")

Amount or date discrepancies alone never invalidate a match
if the invoice number matches.

For Purchase Orders:

Match purchase orders using the PO number referenced on the
already-matched Sales Invoice.

Primary match: PO number (look for "PO", "BC n°", "Order No" on the document)
must match the PO reference found on the invoice.

Fallback: Customer name (must match reference "Libellé")
+ Net amount HT (should be close to invoice net amount).

Amount or date discrepancies alone never invalidate a match.

For Delivery Notes:

Match delivery notes using the BL number referenced on the
already-matched Sales Invoice.

Primary match: Delivery note number (look for "BL", "Delivery Note",
"Bon de livraison") must match the BL reference found on the invoice.

Fallback: Customer name (must match reference "Libellé")
+ date proximity to invoice date.

IMPORTANT: The delivery date on this document determines the revenue
recognition period — it is the triggering event.
Amount or date discrepancies alone never invalidate a match.

For Remittance Advice:

Match remittance advice using the invoice number referenced in
the payment details.

Primary match: The invoice number listed on the remittance advice must
match the invoice number from the already-matched Sales Invoice.

Fallback: Total amount TTC matching the invoice gross amount
+ customer name.

This is the BRIDGE document: it references the invoice (backward link)
and contains the total payment amount that will be used to match
the bank statement (forward link).
Amount or date discrepancies alone never invalidate a match.

For Proof of Payment (Bank Statement):

Match bank statement entries using the payment amount from the
already-matched Remittance Advice.

Primary match: The credited amount on the bank statement must match
the "Montant avis de paiement" (total payment amount) from
the remittance advice.

Verify: The payment date must be AFTER the invoice date
(temporal consistency).
Amount or date discrepancies alone never invalidate a match.

Extraction Model Setup

Sales Invoice (Facture) extraction model:

Field	Type	Description
Numéro de facture	Text	Unique invoice reference (e.g., FA-2024-001, INV-XXX). Must match the reference "Numéro de pièce". Look for "Facture n°", "Invoice No" at top of document.
Date de facture	Date	Date the invoice was issued. Format: DD/MM/YYYY. Usually near the invoice number.
Montant HT	Number	Net amount excluding tax. Format: 1234,56. Must match the reference "Montant HT". Look for "Total HT", "Net Amount".
Montant TTC	Number	Gross amount including tax. Format: 1234,56. Look for "Total TTC", "Amount Due".

Purchase Order (Bon de commande) extraction model:

Field	Type	Description
Numéro de commande	Text	Customer order number (e.g., BC-2024-100, PO #...). Look for the number referenced on the matched invoice.
Date de commande	Date	Date the order was placed. Format: DD/MM/YYYY. Must be BEFORE the delivery date.
Montant HT	Number	Net amount on the purchase order. Format: 1234,56. Should be consistent with invoice net amount.

Delivery Note (Bon de livraison) extraction model:

Field	Type	Description
Numéro de BL	Text	Delivery note reference (e.g., BL-2024-500). Look for the number referenced on the matched invoice.
Date de livraison	Date	CRITICAL: The date goods were physically delivered. Format: DD/MM/YYYY. Look for "Date de livraison", "Delivery Date", "Shipped Date". This date determines the revenue recognition period.

The Delivery Date Determines Revenue Recognition

The delivery date is the triggering event for revenue recognition. It determines WHEN revenue should be recorded. Make sure your extraction model description is very specific about finding the actual delivery date — not the invoice date, order date, or document print date.

Remittance Advice (Détail de règlement) extraction model:

Field	Type	Description
Numéro de facture règlement	Text	The invoice number referenced in the payment. Must match the already-extracted invoice number. Look for "Référence", "Invoice #", "Facture n°".
Montant facture règlement	Number	The invoice amount as stated on the remittance advice. Format: 1234,56. Should match the invoice gross amount (TTC).
Montant avis de paiement	Number	The total amount being paid on this remittance. Format: 1234,56. This is the amount that will be matched against the bank statement.

Why Three Fields on Remittance Advice?

The remittance advice serves as a bridge with three roles:

Numéro de facture règlement links back to the invoice (proving WHICH invoice is being paid)
Montant facture règlement lets you verify the payment covers the right amount
Montant avis de paiement links forward to the bank statement (proving money moved)

Proof of Payment (Preuve de paiement) extraction model:

Field	Type	Description
Date de paiement	Date	Date of the bank transaction. Format: DD/MM/YYYY. Must be AFTER the invoice date.
Montant encaissé	Number	Amount credited on the bank statement. Format: 1234,56. Must match the remittance advice "Montant avis de paiement".

Validation Rules

Chronological sequence checks:

Rule	Configuration	What It Catches
PO before Delivery	Flag if Date de commande > Date de livraison	Delivery happened before the order was placed
Delivery before Invoice	Flag if Date de livraison > Date de facture	Invoice issued before goods were delivered
Invoice before Payment	Flag if Date de facture > Date de paiement	Payment made before invoice was issued

Amount consistency checks:

Rule	Configuration	What It Catches
Invoice vs Reference	Flag if Montant HT (invoice) differs from Montant HT (reference)	Invoice amount doesn't match the ledger
Invoice vs PO	Flag if Montant HT (invoice) differs from Montant HT (PO)	Ordered amount differs from invoiced amount
Invoice vs Remittance	Flag if Montant TTC (invoice) differs from Montant facture règlement	Payment covers the wrong amount
Remittance vs Bank	Flag if Montant avis de paiement differs from Montant encaissé	Money that moved doesn't match the payment advice

Cut-off / period checks:

Rule	Configuration	What It Catches
Delivery before period end	Flag if Date de livraison > December 31, 2024	Revenue recorded in wrong period — goods not yet delivered
Required fields	Flag if Numéro de facture or Date de livraison is empty	Missing critical evidence

What Your Results Will Look Like

Validated row (no issues):

Row	Numéro de pièce	Customer	Ref HT	Invoice HT	Delivery Date	Payment Date	Status
1	FA-2024-1847	Dupont SA	45 000	45 000	27-Dec-2024	15-Jan-2025	✅ Validated

✅ All amounts consistent across the full chain. Delivery before year-end. Payment received after invoice. Complete document chain verified.

Exception row (multiple issues):

Row	Numéro de pièce	Customer	Ref HT	Invoice HT	Delivery Date	Payment Date	Status
3	FA-2024-1855	Leroy Industries	78 200	78 200	03-Jan-2025	20-Jan-2025	⚠️ Exception

⚠️ Two issues detected:

Cut-off issue — Goods were delivered on January 3, 2025, but the sale was recorded in December 2024. This revenue should be deferred to 2025.
Payment amount mismatch — Montant encaissé (bank) differs from Montant avis de paiement (remittance). The difference requires investigation.

More Template Examples

AP Vouching Template

Purpose: Verify recorded expenses are supported by valid invoices.

Category	Required?	Key Extraction Fields
Purchase Invoice	✅ Yes	Invoice #, Vendor, Date, Amount, Description
Purchase Order	❌ Optional	PO #, Approved By, Date
Goods Receipt	❌ Optional	Receipt Date, Quantity, Condition

Key validation: Invoice amount matches recorded expense within tolerance.

Bank Confirmation Testing

Purpose: Match bank confirmation letters to recorded account balances.

Category	Required?	Key Extraction Fields
Bank Confirmation	✅ Yes	Account #, Balance, Currency, Confirmation Date, Bank Name

Key validation: Confirmed balance matches recorded balance.

Once your template is configured:

Save — Template is saved to your library
Duplicate — Create a copy to modify for similar tests
Share — Make available to your team (client or firm level)

For details on sharing and visibility, see Organize Your Models.

Tips for Effective Templates

Tip	Why It Matters
Start simple	Add complexity only when needed
Test on 5-10 transactions first	Catch issues before running on full sample
Iterate on matching instructions	Refine based on what works
Document assumptions	Future users will thank you
Use descriptive field names	"Delivery Date" not "Date1"
Save working templates	Build a library of proven templates

What is a TOD Template?​

Template Components at a Glance​

Step-by-Step: Creating a Template​

Step 1: Name and Describe Your Template​

Step 2: Configure Test Sample Columns​

Step 3: Define Document Categories​

Step 4: Write Matching Instructions​

Step 5: Attach Extraction Models​

Step 6: Set Validation Rules​

Complete Example: Revenue Recognition Testing​

The Audit Objective​

How the Documents Chain Together​

The Test Sample​

Document Categories Setup​

Matching Instructions​

Extraction Model Setup​

Validation Rules​

What Your Results Will Look Like​

More Template Examples​

AP Vouching Template​

Bank Confirmation Testing​

Saving and Sharing Templates​

Tips for Effective Templates​