Function calling (called tool use by Anthropic and Google, and function calling by OpenAI) is a capability of modern large language models that allows them to invoke predefined external functions or tools as part of generating a response — rather than being limited to producing text output. When an LLM with function calling capability determines that it needs to retrieve data, perform a calculation, or take an action to fulfill the user’s request, it generates a structured function call specification (the function name and the arguments to pass it) instead of, or in addition to, text. The calling application intercepts this function call specification, executes the actual function (querying a database, calling an API, running a calculation), and returns the result to the LLM as context for its next response. This call-execute-return cycle can repeat multiple times within a single interaction — the LLM reasoning about what it needs to know, calling functions to find out, and refining its next action based on what it learned. Function calling is what transforms an LLM from a text generator into an active agent capable of taking real actions in external systems.
Function Calling Architecture
| Step | What Happens | Finance Automation Example |
|---|---|---|
| 1. Tool definition | Developer defines available functions with name, description, and parameter schema in JSON | Tool: “query_oracle_ebs_po” — parameters: {po_number: string, entity: string} — returns PO header and line data |
| 2. LLM receives goal | User or orchestration system provides the task; tool definitions are included in the system context | “Process invoice INV-2026-0034 from Al Rajhi Trading — amount SAR 145,000 — validate against PO” |
| 3. LLM decides to call a tool | LLM determines it needs external data and generates a structured tool call | LLM returns: {“tool”: “query_oracle_ebs_po”, “arguments”: {“po_number”: “PO-2025-8821”, “entity”: “SAU-001”}} |
| 4. Application executes | The calling application executes the actual function against the real system | Application queries Oracle EBS REST API with PO-2025-8821; returns PO header, line items, and approved quantities |
| 5. Result returned to LLM | Function output is added to the LLM’s context as a tool result message | PO data returned: SAR 148,000 approved for 200 units; SAR 145,000 invoice for 195 units — within 3% tolerance |
| 6. LLM reasons and acts | LLM analyses the result and either calls another tool or produces a final response | LLM determines match is within tolerance: calls “post_ap_invoice_to_ebs” tool with validated data |
Function Calling for Oracle EPM and EBS Automation
Function calling is the architectural mechanism that connects LLM-based AI agents to Oracle EBS and Oracle EPM Cloud APIs in GCC enterprise automation. A defined tool library for Oracle automation might include: get_gl_account_balance (queries Oracle EBS GL balance for a specified account, entity, and period), run_fccs_consolidation_job (triggers an Oracle FCCS consolidation via the EPM Cloud REST API), get_epm_job_status (polls an EPM Cloud job for completion status), submit_zatca_invoice (submits a ZATCA-formatted XML invoice to the Fatoora clearance API), and escalate_to_finance_team (sends a structured exception notification to the appropriate finance team member via email or Teams). Each tool is a defined function with a schema that the LLM can call when it determines the tool is needed to progress toward the workflow goal — the LLM never directly accesses Oracle; it calls tools that the application executes against Oracle on its behalf.
Parallel Function Calling
Modern LLMs (GPT-4o, Claude 3.5, Gemini 1.5) support parallel function calling — generating multiple tool call specifications simultaneously rather than sequentially, enabling the calling application to execute multiple tools in parallel and return all results at once. For finance automation workflows where multiple independent data fetches are needed (query GL balance for five entities simultaneously, rather than one at a time), parallel function calling reduces total execution time by the number of sequential tool calls — a 5× speedup for five simultaneous queries versus sequential execution. Parallel function calling requires the calling application’s execution layer to support concurrent API calls and to correctly associate each result with its originating tool call specification.
What Goes Wrong in Practice
The most common function calling failure is an LLM that calls a tool with incorrect parameter values — constructing a parameter that is syntactically valid but semantically wrong, such as calling query_oracle_ebs_po with the invoice number instead of the PO number when the invoice references the PO in a non-standard field. Tool definitions must include parameter descriptions and validation constraints that guide the LLM toward correct parameter construction — and the tool execution layer must validate parameters before calling the underlying API, returning a structured error message (not an exception) that the LLM can read and correct in its next tool call.
How Loop Wise Solutions Uses Function Calling
We design function libraries for Oracle EBS and EPM Cloud automation with explicit parameter descriptions, validation constraints, and structured error return formats — enabling the LLM to self-correct parameter errors through the tool result feedback loop rather than failing the entire workflow on the first incorrect parameter construction.
