Korean e-Tax Invoice obligations are not a formatting problem, they are a lifecycle problem. Every taxable supply has to be issued as an electronic tax invoice carrying the supplier and buyer business registration numbers, the supply date, an item-level split of supply value and VAT, and an approval identifier returned after transmission — and once issued, a mistake can only be repaired by a properly typed correction (modified) tax invoice that references the original. ERPNext core gives you an excellent Sales Invoice, Item Tax Templates and a GL, but it has no concept of an approval number, no correction lineage, no rejection state to reconcile against, and nowhere to keep the machine-readable payload you actually transmitted next to the human-readable document your customer received. Finance teams end up re-keying invoices into a separate portal or ASP console, then hand-matching two sets of numbers at VAT return time.

We build a dedicated Frappe app — its own module, DocTypes, permissions and scheduler events — that closes that gap inside ERPNext. A Korea E-Tax Invoice DocType is created from a submitted Sales Invoice through an on_submit doc event registered in hooks.py, so nothing depends on a user remembering an extra button. A mapping layer resolves the supplier and buyer registration numbers, representative name, business type/item classification and address from Company, Customer and Address/Contact records, with a Korea E-Tax Settings single DocType holding issuance defaults, invoice-type and correction-purpose codes, and the ASP/Hometax endpoint credentials as Password fields. Amounts are recomposed from the invoice items and the Sales Taxes and Charges table so supply value, VAT and total reconcile line-by-line to the accounting entry, and a validation pass fails loudly on what Korean issuance actually rejects: a malformed 사업자등록번호 checksum, a missing buyer email for delivery, a supply date outside the permitted issuance window, or a zero-rated line with no exemption reason.

Transmission is deliberately queued rather than synchronous. Server-side whitelisted methods enqueue the payload through Frappe's background workers via frappe.enqueue, so a slow or unavailable endpoint never blocks an accountant's submit, and a scheduler event retries pending documents and polls for outcome. One posting produces both artefacts: the machine format sent to the channel, and a Jinja print format attached to the record and emailable to the buyer, so the copy the customer holds and the copy the authority received come from the same source. Every request and response is written to a child log table with timestamp, endpoint, correlation id and raw payload, and the approval identifier is written back onto both the e-Tax Invoice and a custom field on the Sales Invoice. Rejections land in a distinct Rejected state carrying the returned error code and message, with a guided correction workflow that opens a properly typed modified invoice linked to its original — cancellation, amount change, item change or wrong recipient — so the chain is reconstructible in an audit years later. Read-only access is exposed over the Frappe REST API and whitelisted methods for your reporting stack, and a role profile separates the clerk who prepares from the officer who issues.

This is build-to-order, and we say so plainly: it is not a marketplace app you download today. After a short scoping call we confirm your channel (direct certificate-based Hometax issuance versus a certified ASP provider), your invoice-type and correction-purpose coverage, your Frappe/ERPNext version and your data quality on registration numbers, then quote a fixed scope. Typical delivery is one working week from confirmed scope. The app is installed on a staging bench first, put through a UAT cycle against your real master data with a documented rollback, then cut over to production — followed by a support window and handover of the full git repository, so the code is yours whether or not you keep working with us.