Skip to content

Invoice Generation Module

Applies to: Invoice Generation · Which modules do I have?

Purpose

Configure the module that raises invoices inside Complifly rather than receiving them from an ERP, including its masters, numbering, approval rules and the ledger it maintains.

Audience

Implementation consultants and the customer's finance lead.

Prerequisites

  • INVOICING_ENABLED set for the relevant registrations. It is off by default — a module unlock with legal consequence
  • Customer and item master data collected
  • Numbering scheme decided
  • Approval policy decided by the finance lead
  • Chart of accounts and posting rules agreed, if the ledger is used

Steps

1. Understand what the module adds

Capability Detail
Document creation Invoices, credit notes and debit notes raised in Complifly
Masters Customers with multiple registrations and addresses; items with tax attributes
Numbering Series with a defined format and controlled position
Tax determination Computed from masters and rates, with a preview before committing
Approval Threshold-based, or a multi-level workflow
Receivables A subledger with receipts, aging, write-off and provisioning
General ledger Chart of accounts, posting rules, journals, period close and year-end
Reporting Trial balance, balance sheet, profit and loss, cash flow, aging, statements

This is the module that most changes the shape of an implementation: it moves Complifly from a compliance gateway to a system that originates documents, with the control and accounting obligations that follow.

2. Set up customer and item masters

Master Key considerations
Customers Several registrations per customer are normal; set the default deliberately. Addresses are separate from registrations
Items Classification codes, unit, default rate, and a maximum discount where used
Rates Effective-dated. A rate applied a day early is a real defect — check the dates after loading

3. Define numbering series

Decision Guidance
Format and prefix Per registration and document type as the business requires
Starting position If migrating, continue from the existing position rather than restarting
Uniqueness Must be unique per registration per financial year. A collision produces a permanent duplicate rejection
Who may manage it Series definition is an administrative act, not a transactional one

Numbering is where a migration most often goes wrong. Confirm the current position in the outgoing system before defining the series.

4. Configure credit management

IGM_CREDIT_RULE is one value carrying two decisions: whether credit management runs at all, and what a breach does when it does.

Value Shown in the interface as Behaviour Suits
ALLOW Off Credit limits are recorded on the customer but never checked when an invoice posts Limits held for information only
WARN (default) Warn The invoice is flagged and still posts Most organisations
BLOCK Block The post is refused until a checker records an override Strict credit control

ALLOW was previously labelled "Allow" beside the two enforcement levels, which read as a third enforcement level rather than as the off switch it is. The stored value is unchanged — only the label. A tenant with ALLOW in sys_gstin_feature_config needs no migration.

Two things ALLOW does not switch off:

  • Credit hold. A customer flagged as on credit hold is always blocked, whatever this is set to. It is a per-customer field, not a tenant setting.
  • The Approval Engine. When IGM_APPROVAL_ENGINE is on, a credit-breach trigger in the approval matrix raises its own approval level independently of this flag.

Where it is set. Either the IGM Credit Rule column on the GSTIN's row in Admin & Logs → Operational Controls, or Invoice Generation → Settings → Overview → Credit management, which writes the same sys_gstin_feature_config row. Both need the admin.manage_users permission — an Org Administrator or a Platform Super Admin. A user without it sees the current state read-only, and is told who to ask.

5. Configure approvals

Two mechanisms, and only one is active at a time:

Threshold-based — the simpler gate:

Setting Meaning
IGM_APPROVAL_VALUE_THRESHOLD Value above which approval is required. 0 means off
IGM_APPROVAL_DISCOUNT_PCT Discount above which approval is required. 0 means off
IGM_DISCOUNT_OVER_MAX_ACTION When a line discount exceeds the item's maximum: BLOCK, or APPROVE (allowed but requires approval)

Multi-level workflow — IGM_APPROVAL_ENGINE, which replaces the flat threshold with a configured matrix of levels.

A threshold of 0 means the rule is off, not that everything requires approval. This is the most common misreading of these settings.

Staffing the workflow — do this before you enable it

Configuring the matrix defines the steps. It does not check that anyone can take them, and it will not warn you if nobody can. Each level names an approval role, and a person can only clear that level if both of the following are set on their user record:

Field Set it to
System Role Approver — sign-off only, no processing rights — or Tax Controller for finance staff who both process and approve
Approval Role The level they occupy: Finance Executive, Finance Manager, Finance Controller, Business Head, Plant Head, Director or CFO

Setting one without the other is accepted without error. The person signs in normally and either sees no Approve button or is never routed to.

Check every level in your matrix has a holder — and preferably two

Nothing validates this. A level naming an approval role no active user holds will route documents into a dead end where they sit indefinitely, with no alert to anyone. Walk your matrix against your user list before enabling IGM_APPROVAL_ENGINE, and give each level at least two holders so a single absence does not stall the queue.

Use the Approval Simulator (Invoice Generation > Settings > Approval Engine) to see the exact path a scenario produces, then confirm each role in that path is held. See Segregation of Duties.

Turning the engine off again

IGM_APPROVAL_ENGINE cannot be switched off while any document on that GSTIN is still awaiting approval. The attempt is refused with 409 APPROVALS_IN_FLIGHT and a list of the blocking documents.

This is a control, not a convenience check. Without it the disable would not stop those approvals, it would silently clear them: the legacy flat gate takes over, its thresholds default to 0 (off), and a document routed to three approvers and signed by none is rewritten from PENDING to NOT_REQUIRED and posts. Nothing is rejected, nothing logged.

Clear the queue first. The one case that cannot be cleared — a level whose approval role nobody holds — is why the refusal accepts a force plus a written reason, which cancels the approvals with a full audit trail rather than approving them.

Enabling is unrestricted; only disabling is gated

Switching the engine on needs no check — it starts routing from that moment and does not retrospectively require approval for documents already posted.

6. Configure the ledger, if used

Item Note
Chart of accounts Scoped by company, resolved from party master data rather than from the sign-in organisation. Getting this wrong produces accounts that appear empty
Posting rules Preview them before committing; a wrong rule posts to the wrong account silently
Fiscal calendar Years and periods defined before any posting
Period close Prevents further posting into a closed period
Year-end A pre-check runs before close; work it fully rather than forcing the close

7. Understand the relationship with e-Invoice

A document raised here follows the same compliance path as one received from an ERP: validation, routing, IRN generation, printing. The module originates the document; it does not bypass anything.

Validation

Check Method Pass condition
Module enabled Navigation shows the invoicing screens Present for every intended registration
Masters load correctly Search for a customer and an item Found, with the expected attributes
Multiple registrations per customer work Open a customer with several The default is correct and others are selectable
Rates apply from the right date Raise a document either side of a rate change Correct rate on each
Numbering behaves Raise several documents Sequential, correctly formatted, no gaps or collisions
Tax preview is correct Preview before committing Matches the expected computation
Credit rule fires Raise a document exceeding a credit limit Allows, warns or blocks per configuration
Approval thresholds fire Raise documents above and below the threshold Above requires approval; below does not
Every approval level is staffed Simulate the paths your matrix produces; check each role against the user list No level in use is unheld
An approver can actually approve Sign in as one, open a document pending at their level Approve and Reject are present and succeed
Discount rule fires Apply a discount above the item maximum Blocks or routes for approval, per configuration
Ledger postings are correct Post a document and inspect the entries Correct accounts and amounts
Period close works Close a test period and attempt to post into it Refused
Year-end pre-check works Run it Reports genuine issues rather than passing trivially
Compliance path works Raise a document and take it through to an IRN Reaches generated

Troubleshooting

Symptom Cause Action
Invoicing screens absent Module off for that registration Enable it. It is off by default
Numbering collides after migration Series restarted rather than continuing Numbers are permanently consumed at the registration portal. Correct the series before issuing more
Wrong tax rate Rate effective dates wrong, or the item's default is wrong Check the rate master's dates first
Approvals never required Thresholds left at 0, which means off Set real values
Everything requires approval Threshold set very low, or the workflow engine enabled with a broad matrix Review the settings
A document sits at "Approval pending" and nobody can act The level names an approval role no active user holds Assign that approval role to someone; keep two holders per level
Cannot switch the approval engine off (409 APPROVALS_IN_FLIGHT) Documents still await approval — working as designed Clear them, or force with a written reason if a level is genuinely unstaffed
An approver sees the workflow but no Approve button Their system role does not hold invoice.approve Assign the Approver or Tax Controller system role
An approver can approve but nothing reaches them No approval role assigned, or the wrong one Set the approval role naming their level
A discount is blocked unexpectedly It exceeds the item's maximum and the action is BLOCK Change the action to route for approval, or correct the item master
Ledger accounts appear empty Company scope resolved differently from expectation Accounting objects are company-scoped, resolved from party data, not from the sign-in organisation
Postings land in the wrong account Posting rule wrong Use the preview before committing rules
Cannot post into a period The period is closed Reopen deliberately, with the control implication understood
Year-end close refuses Pre-check found genuine issues Work them. Forcing a close leaves inconsistency that is harder to unpick
A maker can approve their own document Segregation relaxed See Segregation of Duties
Credit limits ignored Rule set to ALLOW Change it if the customer expects enforcement