49. Supplier-invoice statutory tax application
Calculate supplier-invoice tax from exact approved configuration and explicit transaction facts, retain immutable component/recoverability evidence and post its exact provenance without creating broader statutory authority.
Purpose
Calculate supplier-invoice tax from exact approved configuration and explicit transaction facts, retain immutable component/recoverability evidence and post its exact provenance without creating broader statutory authority.
Accounts Payable Accountant creator/submitter; different Finance Controller approver; different Finance Accountant poster; Auditor read-only
SUP-INV-… · INDIA-OPS / SITE-01 · FSL-… v2 · GST-LOCAL-18 · place 29 · basis INR 420.000000 · CGST 37.800000 + SGST 37.800000 · determination fingerprint.
Before you begin
- One active approved statutory profile matches the legal entity, site, country, base currency, classification and invoice date
- An acknowledged PO has exact unallocated eligible receipt quantity
- The selected rule is effective, PURCHASE or BOTH, GOODS or BOTH and NORMAL collection
- Place-of-supply evidence is available when the profile requires it
- CLEAN same-site supplier invoice evidence and different named workflow actors are available
Determination input, retained output and authority boundary
The invoice pins the exact current ACTIVE/APPROVED version at capture. Legal entity, receiving site, country, base currency, classification and invoice date must all agree; later configuration supersession does not rewrite the pin.
Each line selects one exact effective rule. Only NORMAL collection for PURCHASE/BOTH and GOODS/BOTH is authorised here; reverse charge and withholding fail closed for a separate implementation.
The AP user records the evidence-backed code when required. Moduvio does not infer it from addresses, supplier identity, site or tax registration.
At least 20 characters explain why the selected rule and place fact apply. This is retained with exact supplier-invoice evidence and the line fingerprint.
The server applies the pinned inclusive/exclusive price basis, line/document rounding, rule precision and named component rates; callers cannot submit a tax amount.
Each approved component's recoverability percentage produces a retained split. Recoverable tax posts to INPUT TAX; nonrecoverable tax posts to the dedicated NONRECOVERABLE TAX expense control rather than stock.
The header snapshot/fingerprint and immutable line application fingerprints cover the exact profile checksum, rule, transaction inputs, basis, component amounts and rationale. Submit, approve and post revalidate them.
Existing pre-migration invoices remain visibly LEGACY MANUAL for lifecycle compatibility. The current create API cannot create a new legacy or unresolved invoice.
This slice does not calculate customer-document tax, allocate or issue statutory numbers, process reverse charge/withholding, summarize returns, block close for tax exceptions or file with an authority.
Procedure
- 1
Choose the legal entity, eligible acknowledged PO and exact invoice/due dates. Confirm the PO currency and receiving site are correct.
- 2
Select the offered active approved profile version. If no version matches every required dimension and date, stop and have the statutory configuration corrected through Flow 44.
- 3
For each included receipt-backed PO line, enter quantity and unit price, choose one eligible purchase tax rule, enter required place of supply and write the evidence-backed rationale.
- 4
Attach CLEAN supplier-invoice evidence and create the draft. Inspect the returned net basis, tax total, recoverable/nonrecoverable split, component rows and fingerprints.
- 5
Submit, decide and post with different named actors and fresh action evidence. Explicitly accept a price variance where present; no workflow transition can repair a broken tax pin.
- 6
Reconcile the posted journals: GRNI/inventory/variance remain commercial controls, recoverable tax uses INPUT TAX, nonrecoverable tax uses its expense control and AP equals the exact gross amount. Confirm every line carries the tax determination pin.
- 7
For customer tax, reverse charge, withholding, numbering, issuance, returns or filing, stop and use only a later separately authorised capability.
Expected result
- The caller never supplies taxAmount on a new supplier invoice
- The exact active profile/version and effective rule are pinned
- Missing or incompatible profile, rule, currency, date, place-of-supply or classification fails closed
- Inclusive/exclusive and line/document rounding are deterministic
- Component totals reconcile to tax and recoverable plus nonrecoverable equals total tax
- Header and line provenance are database-immutable
- Submit, approve and post revalidate retained fingerprints
- Journal dimensions and source snapshots retain the profile checksum and determination fingerprint
- Balanced posting leaves current stock and stock ledger unchanged
- Reverse charge, withholding, customer tax, statutory numbering, returns and filing remain absent