GPT-6 Astra: Prepare an Expense Draft

Prepare an expense draft from fictional receipts in a disposable workspace. Astra’s documentation includes computer-use support; the computer-use guide describes the surrounding execution pattern and risks. The model’s ability to interact with a screen does not establish that a particular expense application is supported or that its records will be correct.

The outcome here is a reviewed draft and an audit note. Do not connect a first trial to a real reimbursement account or payment method. This is an illustrative workflow design, not a report that we completed an expense claim with Astra.

Create a small practice pack with a transport receipt, a meal receipt, a duplicate and one receipt with an unclear total. Use fictional merchants and no personal account details. Keep the original amount and currency visible. Write the expected totals yourself before requesting extraction.

Provide a simple fictional expense policy in a separate file. State categories and when review is required. Do not ask the assistant to infer your organization’s policy from common practice. Missing policy information belongs in an open question, not in a guessed classification.

Use a test account or local practice form with no ability to submit a real claim. Inspect the execution environment’s permissions and available controls. A sentence saying do not submit is useful task context, but it cannot replace a technical restriction on consequential actions.

Define the permitted pages and files. Keep unrelated browser sessions, credentials and cloud folders out of the practice environment. If you cannot prevent submission or external transmission, use an offline table instead of automating the expense interface.

Ask for a table before any form interaction. Include source receipt, merchant, date, amount, currency, category and review flag. Unknown text should stay unknown. Treat duplicate detection as a separate check that requires evidence.

Prepare a draft expense table from these synthetic receipts.
Use only the supplied policy. Preserve currency and totals.
Flag possible duplicates and unreadable fields with reasons.
Do not submit, pay, email or change account settings.
Stop at the draft review screen; if that boundary cannot be
enforced in the environment, return the table and stop.

Open every source receipt and compare the extracted amount, date and currency. Recalculate totals independently. Two similar amounts are not sufficient proof of a duplicate; compare the source details. Never silently drop a receipt to make the totals match.

Keep different currencies separate unless you supply an approved conversion method and rate source. An apparent arithmetic problem may actually be a unit mismatch. If a receipt is unreadable, ask for a clearer source rather than requesting a more confident guess.

If you used a practice form, compare the visible draft with the checked table. Confirm there was no submission and inspect any activity record available. Save the reviewed table, unresolved fields and a note on what the assistant actually did.

For a real workflow, require the organization’s approval process and appropriate account controls before expanding access. Use the bounded-agent guide to define the task boundary and the document audit workflow for evidence tables. A useful expense assistant reduces preparation work while keeping the final claim easy for a person to verify.

Create two identical fictional transport receipts and one meal receipt with an unreadable total. Write the expected review result before running the task: one possible duplicate pair requiring inspection, and one receipt whose amount remains unresolved. Do not design the fixture so that success requires guessing the hidden number.

Ask the assistant to prepare the table and flag issues. Check whether it preserves both source identifiers for the duplicate pair. Deleting one silently makes the draft harder to audit. For the unclear receipt, the appropriate next step is a clearer source or manual review, not an invented average from the other receipts.

If the practice form supports attachments, compare each draft row with its linked source. Then reconcile the total using the reviewed rows only, while keeping unresolved items outside the approved sum. Label that partial total clearly. This example shows a verification method and expected behavior; it is not a report that Astra processed a real reimbursement claim.

Should a model choose an exchange rate? Supply an approved policy and rate source if conversion is needed. Otherwise, keep currencies separate. Can an assistant decide that a meal is reimbursable? It can apply a supplied rule, but an ambiguous exception needs the organization’s review process.

What if the interface has no safe draft state? Use an offline table and leave form entry to a person. What if the assistant says a submission was prevented? Inspect the actual account activity or test application state rather than relying solely on its narrative. Keep any uncertainty visible and avoid repeating the action until you understand the state. The useful output is an auditable draft with a clear stop, not an automated claim whose correctness is assumed.

Reviewed on 17 October 2026. This is a documentation-based editorial guide with illustrative exercises, not a report of hands-on product testing. Check provider pages for current access, prices, terms and limits.

• OpenAI computer-use documentation
• GPT-6 Astra model documentation

01 Choose a tool: compare the fit. 02 Use a prompt: start with context. 03 Check the result: keep your judgment.