IMOS On-Prem - Invoice Numbering

View IMOS Documentation in the Help Center.

IMOS implements a specific invoice numbering process, which is highly configurable. It is important to evaluate all the options to align IMOS with your organization's invoice numbering requirements.

The IMOS invoice numbering scheme produces invoice numbers for Accounts Receivable (AR) transactions and Accounts Payable (AP) transactions. Invoice numbers are not produced for Ledger Journal (LJ) transactions.

In addition to default behavior, several configuration options are available for invoice numbering. When designing an invoice numbering solution, it is important to take into consideration the following:

• Automatic vs. manual numbering
• Invoice number sequence
• Invoice number uniqueness
• Handling reversal transactions

These characteristics are used in describing the different configuration options below:

• Default Configuration Behavior
• Additional Supported Business Processes
• Invoice Numbers by Company
• Document Numbers

Default Configuration Behavior

The default invoice numbering scheme operates on the principle that AR transactions should be automatically numbered, and that AP transactions should allow for manual invoice numbers to match the number provided by the vendor/counterparty. An invoice number is generated as soon as an invoice is saved, with a status of either Pending or Actual. (Saving a Miscellaneous Revenue with status Pending does not generate an invoice number.)

Accounts Receivable Invoices

The default invoice numbering scheme for AR invoices is NNNNNNSSSS, where:

• NNNNNN is a number starting at 000001 and incrementing independently for each Bill Source. Each invoice source has its own available set of numbers. For example, the first Freight Invoice will be 000001FINV while the first Miscellaneous Revenue will be 000001VREV.
• SSSS is the four-letter Bill Source of the invoice.

The system enforces uniqueness for AR invoice numbers by controlling the invoice numbers.

Time Charter Out Bills

There is one exception to the automatic numbering: Time Charter Out Bills (TCOB). By default, users can override a TCOB invoice number. If a user does not enter an invoice number, a number is automatically generated based on the principle above. However, if a user manually enters an invoice number, that number is saved.

Deleted Invoice Gaps

If an invoice document is deleted, AR invoice numbers are not reused. For example,  if a user creates an invoice, therefore locking in a number, and then another invoice of the same type is created with the next available number, when the first invoice is subsequently deleted, there will be a gap in the invoice numbering.

Breakdown of this example:

1. User creates a Miscellaneous Revenue invoice for a deviation and reserves invoice number 000001VREV.
2. User creates a second Miscellaneous Revenue for a different purpose and reserves invoice number 000002VREV. This invoice is approved and posted.
3. User's deviation revenue is rejected by a manager and the user is told to include it on the Freight Invoice, so the user completely deletes invoice number 000001VREV.
4. User creates a third Miscellaneous Revenue and reserves invoice number 000003VREV.
5. Final result:
   
   1. 000001VREV - Deleted/Gap
   2. 000002VREV - Posted
   3. 000003VREV - Actualized

Accounts Payable Invoices

The default invoice numbering scheme for AP invoices is to allow users to manually enter the invoice number. Users may enter up to 50 characters.

By default, the system does not enforce uniqueness for AP invoice numbers. Two separate AP invoices may have the same number, even for the same vendor.

Invoice Transaction Reversals

Both AP and AR invoices may eventually go through a reversal process. As per default behavior in IMOS, an invoice that is reversed will result in the following:

1. A reversal transaction is automatically posted to the ledger with a specified accounting date.
2. The original transaction is indicated as reversed, and the underlying Operations invoice is reverted to a Pending status.
3. If the pending invoice is subsequently saved again:
   • For AR invoices, a new invoice number is assigned based on the next available number in the set.
   • For AP invoices, the user will need to enter a new invoice number manually.

In the above scenario, the following occurs to the invoice numbers:

1. The initial posted transaction remains in the ledger with the original invoice number and original transaction number.
2. The reversal transaction is posted to the ledger with the original invoice number and a reversal transaction number.
3. The updated invoice receives a new invoice number and a new transaction number.

AR Invoice Reversal Example

Scenario: An operator creates, approves, and posts a Freight Invoice. When the charterer disputes the Freight Invoice, the accounting team reverses the original Freight Invoice, and then the operator updates the Freight Invoice. Finally, the operator approves and posts the Freight Invoice a second time.

Breakdown:

1. Operator creates a Freight Invoice with invoice number 000001FINV.
2. Accounting team posts Freight Invoice 000001FINV, and it now has transaction number 17COMP0000001N.
3. Charterer disputes the Freight Invoice.
4. Accounting team reverses the Freight Invoice.
   • • The reversal transaction has invoice number 000001FINV and transaction number 17COMP0000001R.
     • The Freight Invoice reverts to Pending status with no invoice number.
5. Operator updates the Freight Invoice with correct details and saves; freight invoice number 000002FINV is assigned.

Additional Supported Business Processes

Several configuration flags allow for overrides in the default behavior, typically for certain business use cases. Keep in mind that mixing and matching these configuration flags is allowed, but results may be unexpected. Be sure to make changes in a testing environment before committing any invoice numbering changes to a production environment.

Auto Numbering TCO Bills

The Time Charter Out Bill invoice number field can be locked down. This is a valuable configuration for organizations that want to guarantee that all AR invoices have an automatically generated invoice number. To lock down the TCOB Invoice Number field, set configuration flag CFGLockTCOBInvNo to Y.

Auto Numbering Time Charter In Payments

Some organizations may want Time Charter Payments to have controlled invoice numbers. This is especially true if the charterer is responsible for generating statements and hire payment details before issuing cash payment to the owner. To support this use case, IMOS can be configured to generate only Time Charter Payment (bill source TCIP) invoice numbers automatically. The number will be generated upon first save. Other AP invoices will still have manual invoice number fields.

Two configuration flags trigger automatic TCIP numbering, but only one flag can be used at a time. If both flags are set accidentally, the value of CFGCustomTCIPInvNo takes precedence.

• CFGAutoGeneralTCIPInvNo: When set to Y, TCIP invoice numbers are generated in the format [TCI Code] [Vessel Name] Hire [Hire Number]. For example, if I take the MV AKTAIA on time charter, and my TCI Code is AKTA-I0001, then my first TC hire payment will have the invoice number AKTA-I0001 MV AKTAIA Hire 1.
• CFGCustomTCIPInvNo: When set to Y, TCIP invoice numbers are generated in the format [TCI Code]-[Hire Number]. For example, if I take the MV AKTAIA on time charter and my TCI Code is AKTA-I0001, then my first TC hire payment will have the invoice number AKTA-I0001-1.

Auto Numbering All Account Payables

Some organizations have control processes around Accounts Payable that require an internal number to be generated for all payable documents. In IMOS, this is accomplished by using CFGAutoNumberPayables. When enabled, invoice numbers are automatically generated for AP invoices.

The invoice number will be generated when the invoice is first created with status Pending. The exception to this rule is a Miscellaneous Expense. The Miscellaneous Expense must be status Actual before IMOS will generate an invoice number.

The format for the invoice number is NNNNNNSSSS, where:

• NNNNNN is a number starting at 000001 and incrementing independently for each Bill Source. Each invoice source has its own available set of numbers. For example, the first Miscellaneous Expense will be 000001VEXP.
• SSSS is the four-letter Bill Source of the invoice.

This configuration does not lock the Invoice Number field the same way the AR invoice number field is locked. A user can still manually enter an AP invoice number. Once entered, the invoice number may be overridden until the invoice is approved as part of the approvals workflow.

This flag will also naturally create uniqueness for the invoice number, but only if the end user does not override the generated number.

When this flag is enabled along with either of the Time Charter In Payment auto-numbering configurations, the formatting for the TCIP invoice number will follow the TCIP-specific configuration flag, not the CFGAutoNumberPayables flag.

Preventing Duplicate Invoice Numbers

There are two options for preventing duplicate invoice numbers. These options are targeted towards AP invoice transactions; AR invoices are almost always controlled via IMOS, which never assigns a duplicate invoice number. The configurations are similar, but the subtle difference may be important to an organization.

Check for Duplicates in Operations (Before Posting)

Invoice numbers are checked for duplicates against other existing Operations invoice records. In theory, this prevents ever having a duplicate invoice number for the specific invoice types supported by the flag. To enable this configuration, set the configuration flag CFGCheckDuplicateInvNoInOps to Y. When enabled, there are several changes to IMOS:

• In general, an invoice cannot be saved if it has the same invoice number as another invoice for the same vendor.
• IMOS will check against Operations invoices, which are invoices that are status Pending, Actual, or Posted.
  
  • When an AP invoice is set to status Actual on the Voyage Other Revenue/Expenses form, IMOS will check if the invoice number is already in use for the vendor.
  • If an invoice number is manually entered on the Profit Share Distribution form, IMOS will check if the invoice number is already in use for the vendor when the user clicks .
  • When an AP invoice is entered directly on the Transaction Data Entry form, IMOS will check if the invoice number is already in use for the vendor when the user clicks .
  • When any AP or AR invoice reaches Posting stage, IMOS will check if that invoice number is already in use for that vendor when the user clicks .
• When an invoice is reversed, a new Invoice Number is generated:
  • For AR invoices, that is the next number in the available set.
  • For AP invoices, by default, -R is appended to the invoice number to make it unique (controlled by configuration flag CFGAppendRToReversalInvoiceNumber).

Alternatively, if you set CFGCheckDuplicateInvNoInOps to A, an invoice cannot be saved if it has the same invoice number as another invoice for the same vendor within the same Account Period. This refers to the default Account Period (with no Company specified).

Check for Duplicates in Financials (At Posting)

Invoice numbers can also be checked for duplicates against only invoices that are already posted. This is accomplished by setting the flag CFGCheckDuplicateInvNoInAct to Y. Effectively, this means users can create invoices with the same invoice number, but when the user attempts to post, IMOS will check if a posted invoice for that vendor already has the invoice number. This is primarily used when interfacing with accounting systems.

When this flag is enabled, there are several changes to IMOS:

• In general, an invoice cannot be posted if another posted invoice with the same invoice number for the same vendor already exists.
• When an invoice is entered directly on the Transaction Data Entry form, IMOS will check if the invoice number is already in use for the vendor when the user clicks .
• When an invoice reaches Posting stage, IMOS will check if that invoice number is already in use for that vendor when the user clicks .
• When an invoice is reversed, a new Invoice Number is generated that is the next number in the sequence (depending on whether you are using default numbering or numbering by company).
  • If the Invoice Number is manually entered (as is the case in the default AP numbering scheme), -R is appended to the invoice number to make it unique.

Alternatively, if you set CFGCheckDuplicateInvNoInAct to A, an invoice cannot be saved if it has the same invoice number as another invoice for the same vendor within the same Account Period.

Invoice Numbers by Company

It is possible to use automatically generated invoice numbers that use the linked Type W Company Code as part of the invoice number. This is instead of using invoice numbers that are linked to the Bill Source, which is the default behavior.

To enable company-based invoice numbering, set the configuration flag CFGInvoiceNoByCompany to Y. When enabled, an invoice number is automatically generated in the format CCCCNNNNNN, where:

• CCCC is the four-letter company code of the linked company.
• NNNNNN is an incrementing number, starting from 000001. All invoices that are auto-generated for this company will draw from the same set of invoice numbers, selecting the next available number regardless of Bill Source type. The number of characters used for the company code can be controlled via CFGCompanyCodeLengthOnInvNo.

For example, if a company has company code COMP and generates a Freight Invoice first, the Freight Invoice will have invoice number COMP000001. If the company then creates a Miscellaneous Revenue, it will have invoice number COMP000002.

By default, AR invoice numbers are automatically generated only when company-based invoice numbering is enabled. If CFGAutoNumberPayables is enabled, AP invoices are included as part of the set for the next available invoice number. If unique Time Charter invoice numbering is enabled, those invoice numbers will take precedence over company-based invoice numbers.

Reversals in Company-Based Numbering

Reversal transactions are handled differently in company-based numbering (using CFGInvoiceNoByCompany). Depending on your organization's principles it will be important to make the correct decision on which configuration flags to use.

Default Company-Based Reversals

When only CFGInvoiceNoByCompany is enabled, IMOS has the following behavior with reversals:

• When an invoice is reversed, the reversal transaction uses the same invoice number as the original invoice.
• The original invoice number is returned to the company invoice number set.

Example:

1. Operator creates, approves, and posts a Freight Invoice with invoice number COMP000001.
2. Accountant reverses the Freight Invoice.
   • The reversal invoice number is COMP000001.
   • The original posting also retains invoice number COMP000001.
3. Operator creates a Demurrage Invoice and saves it. The Demurrage Invoice number is COMP000001, because the number from the reversed Freight Invoice has been returned to the invoice number set.

Company-Based Reversals Without Returning Invoice Number to the Available Set

Some organizations may not want to reuse an invoice number if it has already been posted. It is possible to configure IMOS to block returning an invoice number to the available set by setting CFGInvNoByCompanySkipGap to Y. When the configuration is enabled, IMOS has the following behavior:

1. When an invoice is reversed, the reversal transaction uses the same invoice number as the original invoice.
2. The original invoice number is not returned to the available set, any new invoice will use the next available number.
3. The length of invoice numbers increases by two: CCCCNNNNNNNN.

Same example as above, but with this configuration enabled:

1. Operator creates, approves, and posts a Freight Invoice with invoice number COMP00000001.
2. Accountant reverses the Freight Invoice.
   • The reversal invoice number is COMP00000001.
   • The original posting also retains invoice number COMP00000001.
3. Operator creates a Demurrage Invoice and saves it. The Demurrage Invoice number is COMP00000002, because the number from the reversed Freight Invoice is blocked from the available set.

Company-Based Reversals With Different Invoice Numbers

Further to the above, some organizations may not want to reuse the same invoice number for the reversal transactions. This ensures that each posted transaction has a unique invoice number. To enable this, you may use either CFGCheckDuplicateInvNoInOps or CFGCheckDuplicateInvNoInAct along with company-based invoice numbering.

Enabling this configuration CFGInvoiceNoByCompany has the same effect on reversals as described above.

Same example as above, but with this configuration enabled:

1. Operator creates, approves, and posts a Freight Invoice with invoice number COMP000001.
2. Accountant reverses the Freight Invoice.
   • The reversal invoice number is COMP000002.
   • The original posting retains invoice number COMP000001.
3. Operator creates a Demurrage Invoice and saves it. The Demurrage Invoice number is COMP000003, because the number from the reversed Freight Invoice has incremented the available set.

Finally, it is possible to combine the duplicate-checking flags with CFGInvNoByCompanySkipGap to ensure that a reversed invoice number is not added back into the invoice number set. It is considered best practice to combine these configurations.

Document Numbers

In addition to the default numbering scheme and company-based numbering, a third option is available for controlling invoice numbers: Document Numbers. Document Numbers are enabled by setting CFGEnableDocumentNumbers to Y. Document Numbers enable you to automatically generate invoice numbers based on a user-defined pattern, instead of an IMOS-defined pattern. Much of the functionality around the Document Numbers setup form is explained on the Document Numbers page; this page focuses on the impact of those configurations.

Document Numbers Invoice Number Sets

Document Numbers will generate invoice numbers automatically for any of the invoice categories specified on the form, based on the patterns entered on the form. The categories have a hierarchy, which is followed to determine which invoice number set to draw from per invoice.

• AR: The AR number set specifies the available invoice numbers for all Accounts Receivable invoices.
• ARREV: The ARREV number set specifies the available invoice numbers for reversal transactions of AR invoices; if no ARREV is specified, IMOS will default to the next available AR invoice number.
• AP*: The AP number set specifies the available invoice number for all Accounts Payable invoices; to leverage this feature completely, enable CFGAutoNumberPayables.
• APREV*: The APREV number set specifies the available invoice numbers for reversal transactions of AP invoices; if no APREV is specified, IMOS will default to the next available AP invoice number.
• DA: The DA number set specifies the available invoice numbers for Port Expense invoice types, but only when imported from an external system such as DA-Desk. A DA created directly in IMOS will use the AP invoice number set.
• XOTH: The XOTH number set specifies the available invoice numbers for XOTH invoice types.

* Note: In order to have Document Numbers auto-generate AP, you must enable configuration flag CFGAutoNumberPayables.

Document Numbers Deleted Invoice Gaps

Document Numbers functionality handles deleted invoice number gaps in a different manner from both the default configuration and company-based invoice numbering. Configuration flag CFGDocNoTableScan further enhances gap handling. The difference between gap handling with and without the additional flag is subtle, so it is important for your organization to understand the difference before choosing which to implement.

Default Deleted Invoice Gaps

By default, Document Numbers handles deleted invoices by returning the deleted invoice number to the set, but only if it is also the next available invoice number. For example, if a user creates an invoice with number COMP000001, and then deletes it immediately, COMP000001 will return to the invoice number set. However, if a second invoice, COMP000002, is created after COMP000001, and  COMP000001 is deleted, the number is not returned to the invoice number set.

Example breakdown:

1. Operator creates Miscellaneous Revenue COMP000001.
2. Operator deletes Miscellaneous Revenue COMP000001 immediately.
3. Operate creates a Freight Invoice immediately after; it will receive invoice number COMP000001.

However, with a second invoice created in between:

1. Operator creates Miscellaneous Revenue COMP000001.
2. Operator creates Freight Invoice COMP000002.
3. Operator deletes COMP000001.
4. Operator creates a third invoice, a Demurrage Invoice; it will receive invoice number COMP000003.

Deleted Invoice Gaps with CFGDocNoTableScan

An enhancement to Document Numbers is available for handling invoice number gaps. To enable this feature, set configuration CFGDocNoTableScan to Y. When enabled, any deleted invoice number is returned to the available invoice number set, regardless of the sequence.

Example: A user creates an invoice with number COMP000001, then immediately creates a second invoice with number COMP000002. The user then deletes invoice COMP000001. If a user creates a third invoice, it will receive invoice number COMP000001, because the number was returned to the invoice number set.

Breakdown:

1. Operator creates Miscellaneous Revenue COMP000001.
2. Operator creates Freight Invoice COMP000002.
3. Operator deletes COMP000001.
4. Operator creates a third invoice, a Demurrage Invoice; it will receive invoice number COMP000001.

Using this flag ensures that there are never any invoice number gaps when using the Document Numbers invoice numbering scheme.

Use With Other Flags

Document Numbers is considered a complete invoice numbering solution. Therefore, its interaction with other configuration flags can have mixed results. Below are some notes about interactions between Document Numbers and other configurations.

• CFGInvoiceNoByCompany: The interaction of Document Numbers and company-based invoice numbering can have mixed results; thus, it is best practice for an organization to pick one of the schemes and stick with it. Note: It is possible to reproduce the effect of company-based invoice numbering using the Document Numbers mechanism.
• CFGAutoNumberPayables: As noted above, you must enable this flag if you want to include AP invoices as part of the Document Numbers scheme.
• CFGCheckDuplicateInvNoInOps and CFGCheckDuplicateInvNoInAct: If APREV and ARREV invoice number sets are not specified, Document Numbers will default to using the same invoice number for a reversal. However, if either of these flags is enabled, a new invoice number is used for the reversal transaction.
• CFGAutoGeneralTCIPInvNo and CFGCustomTCIPInvNo: If either of these flags is enabled along with Document Numbers, the TCIP-specific invoice number set is used by default rather than the Document Numbers AP invoice number set.