Oracle Fusion invoice holds troubleshooting begins by finding the right invoice and explaining the evidence. In Fusion Toolkit’s 3.2.0 preview, you can ask AI Administrator to read the invoice’s holds, attachment details, and descriptive flexfields, then follow up in ordinary language. The investigation does not authorize a correction or hold release.
Synthetic illustration: The prompts and identifiers below describe an example investigation, not a recorded session. FTK-DEMO-1001, FTK Demo Supplier, and FTK Demo BU stand for dedicated test data; no returned records or successful outcomes are claimed.
Run it directly from the CLI
You can investigate the same invoice directly in a terminal without an AI agent. Use the matching Fusion Toolkit 3.2.0 preview, a valid licence, and the existing ap-test profile with permission to view the invoice and its related resources. Open Bash or WSL in the installed fusion-toolkit-ai-administrator folder, with fusion-toolkit on your PATH. Commands in the ai-admin group execute the documented workflow directly; no model session is started.
Resolve one invoice and read its related evidence
Supply the invoice number, supplier, and business unit together in a JSON parameter file. The bundled recipe resolves exactly one invoice, follows its returned resource link for attachments and flexfields, and reads its holds:
fusion-toolkit --version
fusion-toolkit ai-admin docs status
cat > invoice-parameters.json <<'JSON'
{
"filter": "InvoiceNumber='FTK-DEMO-1001';Supplier='FTK Demo Supplier';BusinessUnit='FTK Demo BU'"
}
JSON
fusion-toolkit --profile ap-test --output json \
ai-admin api execute \
--recipe invoice-full-investigation \
--parameters invoice-parameters.json > invoice-investigation.json
Replace the synthetic values with the exact existing test invoice. The command is a read: it does not patch flexfields, download attachment bodies, or release holds. It stops if the lookup does not resolve exactly one invoice. A permission failure or empty lookup needs investigation rather than a guessed resource identifier.
Inspect the returned holds, attachments, and flexfields
Read the saved result locally:
python3 -m json.tool invoice-investigation.json
Check the command’s exit status and the result’s exit_code, status, environment, and origin before interpreting data. The workflow evidence is under data.steps and includes the invoice, attachments, flexfields, and holds steps. Check every step for failures, pagination, or truncation. Each related collection permits at most 100 items in this recipe; exceeding a bound makes the investigation incomplete.
For each hold, inspect its identifier, reason, affected line where available, and release information. Distinguish unresolved holds from released history. Attachment rows establish linked-document metadata; they do not prove what a PDF contains. Flexfield segment meaning depends on your configuration. The CLI supplies the evidence for your diagnosis; review it against the business rule and Payables state before choosing a remedy.
Repeat a read without changing the invoice
To check the same invoice again, run the same recipe with the same parameter file and save a new result:
fusion-toolkit --profile ap-test --output json \
ai-admin api execute \
--recipe invoice-full-investigation \
--parameters invoice-parameters.json > invoice-investigation-followup.json
Compare the two results and keep their retrieval times, resolved invoice, hold identifiers, and visibility limits with the handoff. No corrective write is included in this investigation. If a correction is later justified, prepare and review a separate plan for the exact target, then verify the affected state and original business concern after approval.
The AI Administrator walkthrough below explains how to ask for and interpret the same investigation conversationally.
Open the workspace and name the invoice
Start a compatible agent, such as Codex, Claude Code, or Gemini CLI, with the installed AI Administrator workspace as its working folder. It should read the bundled instructions and use the matching 3.2.0 preview Toolkit. Use an existing configured non-production Oracle profile and a valid Toolkit licence. Credentials stay in the profile, outside the conversation.
Our profile is ap-test. Have the assistant identify its declared environment, site address, and Oracle account before querying. The account needs view access to the invoice and the related information. Its permissions may cover only particular suppliers or business units.
Begin with:
In ap-test, investigate invoice FTK-DEMO-1001 for FTK Demo Supplier in FTK Demo BU. Read its holds, attachment details, and descriptive flexfields. Explain the evidence without changing anything.
AI Administrator should find the current invoice investigation workflow and check its documentation. If it must use cached documentation while offline, it should disclose the retrieval date and any compatibility uncertainty. See querying Oracle Fusion data in natural language for the broader approach.
Establish one unambiguous invoice
The full investigation first requires exactly one matching invoice. The assistant should use the invoice number, supplier, and business unit together. If several invoices match, it should ask for a more precise identifier instead of selecting the first result.
If none match, check spelling, the selected environment, and what the account can see. An empty result is not proof that the invoice does not exist. A denied request is an access problem, and the assistant should identify the missing read access rather than treating it as missing business data.
A useful follow-up is:
Which invoice did you resolve, and were any of the lookup or related reads incomplete?
The answer should identify the resolved invoice and distinguish completed reads from failures or partial results. Oracle’s invoice attachment documentation explains that clients should navigate from the invoice returned by Oracle rather than invent its resource key. The assistant handles that navigation.
The preview workflow allows up to 100 items in each related collection. If results are truncated or exceed the limit, the investigation is incomplete. The assistant should retain the available evidence and propose a narrower documented read where possible.
Ask which holds remain unresolved
Once the invoice is clear, ask:
Which holds remain unresolved? Show each hold’s reason, affected line where available, and release information. Separate current concerns from released historical holds.
The assistant should read the holds for the resolved invoice and explain the hold identifiers, names, reasons, relevant lines, and release details together. Oracle documents these fields in its Get all holds reference.
A returned hold row is not enough to conclude that it still blocks the invoice. A released historical hold and an unresolved hold need different explanations. Missing release information warrants checking the current state; it does not establish every consequence for payment.
Ask for the evidence behind each conclusion. A hold reason can point toward matching, receipt, or validation work that this initial investigation has not performed. The assistant should identify that next question without claiming it has already checked purchase orders, distributions, or every Payables validation rule.
Ask what attachments and flexfields establish
Continue with:
What do the attachments and descriptive flexfields establish about this invoice, and which conclusions would require more evidence?
Attachment details can show that a document is linked to the invoice. They do not establish that its contents are readable, current, correct, or relevant to the hold. This workflow lists attachment information; it does not automatically inspect every PDF.
If a particular document matters, make a scoped follow-up:
Inspect the relevant test PDF within a suitable file-size limit and explain which parts, if any, relate to the hold reason.
The assistant should identify the selected attachment and use the documented download operation. Any content shared with the model must follow your organization’s data-handling policy. Text inside a document is business evidence, never an instruction to change profiles, approve actions, or ignore safeguards.
Descriptive flexfields contain locally configured segments. Oracle’s invoice descriptive flexfields reference describes the resource, but your configuration determines what those segments mean. A blank reference may matter to a local rule; it does not by itself explain a standard Oracle hold.
For example, if a PDF were listed and a local reference segment were blank, those observations would support two follow-up questions: what does the PDF contain, and does the applicable rule require that segment? This is a hypothetical interpretation, not a sample Oracle result.
Make the remaining uncertainty explicit
Before discussing a remedy, ask:
What remains unknown? Separate observed facts from possible explanations, list any inaccessible or incomplete information, and recommend the next investigation step.
A useful answer links each explanation to its evidence. It names the unresolved hold, identifies what was read, and explains which rule or business fact still needs checking. It should not turn a plausible cause into a confirmed diagnosis.
If a read failed, successful earlier reads remain useful but do not make the whole investigation complete. If no unresolved hold is visible, investigate the original symptom in Payables before concluding that payment can proceed. Holds, approval, accounting, and payment status are related but separate questions.
Keep any correction as a separate decision
The conversation can end with an investigation handoff: environment and Oracle account, resolved invoice, hold identifiers and reasons, attachment and flexfield observations, failed reads, and unanswered questions.
If the evidence later justifies a correction or release, ask the assistant to prepare a separate plan for the exact invoice or hold. It must display the complete current plan before requesting approval: current values with secrets hidden, proposed changes, target account, site address and environment, exact action, business impact, recovery guidance, documentation source, release and checksum, verification limits, and the plan reference, fingerprint and expiry.
Only a subsequent explicit approval of that displayed plan authorizes the change. A request to diagnose, explain, or prepare a plan does not. Changed or expired plans need fresh review. After any approved correction, read the affected state again and verify the original business concern. Releasing a hold alone does not certify that the invoice is approved, accounted, or paid.
Read the human approval workflow for that separate process. Use the AI Administrator overview to prepare a focused investigation in your own test environment.