Swiss QR-bill processing in Oracle Fusion Payables begins with the payment data inside the invoice attachment. Recognizing an invoice header does not establish that its QR payment reference has reached the field used by your payment integration. A configured hold can keep that exception visible until enrichment is complete.
Define the customer's mapping before automating it. Identify the expected creditor account, reference type and reference value, then confirm where the payment payload belongs in Oracle. The configured hold and release names must match a workflow that permits that release. A QR correction does not resolve unrelated matching or tax exceptions.
Use the current SIX QR-bill specifications to validate the payload. Structured address fields and supported characters need representative documents. Check the relevant currency and reference rules rather than treating any decoded QR code as an acceptable payment instruction.
Fusion Toolkit's qr-bill-invoice-hold-processor finds invoices with the selected hold, retrieves a PDF attachment and decodes the QR payload. Its reviewed transformation prepares the invoice update. A live run attempts the invoice update before the matching hold release. If extraction or the invoice update fails, the processor does not proceed to release that hold.
Begin with fusion-toolkit --profile ap-test qr-bill-invoice-hold-processor --holdName QR_DATA_TEST_HOLD --releaseName QR_DATA_TEST_RELEASE --directory output/qr --dry-run --stats-file output/qr-stats.json. The hold names are synthetic. Dry-run mode performs reads and local document extraction while skipping the invoice update and hold release.
Review the decoded values against the printed payment section and the intended Oracle mapping. Test blurred scans and invoices with several attachments. The current processor selects the first PDF attachment it encounters, so an unrelated supporting document can become an extraction failure. Protect the working directory because it contains supplier documents and decoded payment data.
After the dry run, test a small live batch in a non-production environment with the required privileges. Verify the populated invoice field and the exact hold state separately. If the update succeeds but release fails, inspect both records before another run. Repeating the whole workflow without reading the current state can hide a partially completed change.
Record processed and failed counts together with the process exit code. Prevent concurrent runs against the same invoice queue. The monitoring and recovery guide explains why a lost response requires investigation before resubmission.
Measure the result against observed AP work. Count eligible invoices and compare the time spent retrieving documents and entering payment data with the remaining exception review. Keep decoding failures in the comparison. This guidance was reviewed on 8 November 2026.
Use the Toolkit documentation to configure a test hold and mapping, then run a dry extraction on representative Swiss QR-bills before enabling invoice updates.