TL;DR: GPT-6.1 Terra makes visual computer use cheaper and more capable according to OpenAI's October 26 announcement. An accounts-payable team should evaluate that improvement against completed, reconciled invoice records, including exceptions and review time. A correct screenshot interpretation is useful evidence; it does not establish that the right supplier was paid, a duplicate was avoided, or a failed submission was recovered correctly.
The most revealing invoice in an automation trial is often the one marked almost finished. The model read the document, opened the accounting application, selected a supplier, and entered a plausible amount. A final confirmation never arrived. The demonstration looks successful until someone asks whether the organization now owes a supplier twice, once, or not at all.
OpenAI introduced GPT-6.1 Terra as a model for detailed visual reasoning, computer use, and writing, with availability through its API and supported ChatGPT Work and Codex plans. Its announcement reports improvements on computer-use benchmarks and lower standard token prices than GPT-5.6 Terra. Those are maker-reported results, rather than measurements of an invoice department. They justify a new trial, with a business outcome as its endpoint. OpenAI launch announcement
The trial below belongs to a fictional distributor called Alder Supply. Every invoice, workload figure, and cost calculation is invented. The exercise explains how an operations team can turn a model release into a purchasing decision. It is not accounting advice, a claim about OpenAI's customers, or a report of a deployed integration.
The department orders a completed record
Alder's invoice clerk currently receives documents from several channels and enters approved invoices into an accounting system. The team wants help with document reading and repetitive screen interaction. It does not want to delegate supplier onboarding, approval of new bank details, or the final release of funds merely because those controls happen to appear near the entry form.
The first trial contract therefore defines an accepted outcome precisely. The invoice belongs to the correct legal supplier, contains the supported line and tax treatment, references the appropriate purchase context, has passed the department's existing approval process, and appears once in the authoritative accounting record. The automation retains a link to the source document and the resulting record identifier.
An unresolved invoice is another legitimate outcome. A missing purchase reference can enter an exception queue with the missing evidence identified. That is preferable to inventing a reference so the automation can report completion. Alder measures both accepted records and correctly routed exceptions, while preserving the distinction between them.
The team writes these conditions before choosing a reasoning setting or comparing screenshots. Otherwise it risks optimizing the most visible part of the task while leaving the real work to a clerk who must inspect every output afterward. The model's contribution should be evaluated within the whole process that the department actually purchases.
Receipt one: the amount was readable and the supplier was wrong
The first fictional invoice is clearly printed. Its supplier name resembles an existing vendor, but the legal entity differs by one word. The model extracts the total correctly and selects the familiar vendor from the application's autocomplete list. Every typed character looks reasonable. The record is still unsuitable for acceptance.
Alder's reviewer separates extraction from entity matching. The document's printed name, registration details where relevant, and the organization's approved supplier record provide different evidence. A high confidence score for reading the name does not establish that the selected internal vendor is the same counterparty. The system must preserve the extracted evidence rather than merely present a completed form.
The trial includes similar names, trading names, and invoices sent by an authorized billing service. These are not deliberately bizarre adversarial documents. They represent ordinary ambiguity that an employee currently resolves through established records or a follow-up question. The automation should either demonstrate the required match or route the case for that resolution.
A useful exception says that the document identifies one entity while the chosen account describes another, with links to the relevant fields. A vague low-confidence flag makes the reviewer rediscover the problem. Alder times that rediscovery work because a cheap model can create expensive review if its uncertainty is poorly localized.
This receipt is accepted only after the supplier relationship is resolved through the normal process. The model is not rewarded for selecting a likely candidate quickly. Its useful contribution is preparing the evidence, narrowing the alternatives, and avoiding an unsupported final choice.
Receipt two: the green banner disappeared before anyone read it
The second invoice reaches the Save button. A transient notification appears, the browser disconnects, and the agent returns to a blank form. Retrying seems sensible. It could also create a duplicate if the first submission succeeded and only its acknowledgment was lost.
Alder distinguishes a request to save from evidence that a record exists. The recovery workflow looks for the outcome through the application's supported search or integration interface before deciding whether another submission is appropriate. The exact mechanism depends on the accounting product. A production design should consult that product's documented behavior rather than assume every application supports the same duplicate detection.
The invoice's stable business reference helps the investigation, but it is not automatically a globally unique identifier. Two suppliers can use the same invoice number. A corrected invoice can preserve a reference while changing an amount. The team's matching policy includes the supplier relationship and other relevant context, with ambiguous cases left for review.
This case also exposes a weakness in screenshot-only scoring. A captured success banner can demonstrate what the interface displayed at a moment. It does not necessarily establish the durable accounting state, and its absence does not prove that the save failed. Alder's test record includes the final authoritative record identifier or a clearly unresolved state.
The important recovery outcome is a decision that remains correct after uncertainty about delivery. If a reviewer must stop the automation and investigate, that interruption belongs in the trial's time and cost. It should not disappear because the first attempt looked almost complete.
Receipt three: the total adds up only after an invented adjustment
The third invoice contains three line items, a discount, and tax. The model reads the gross amount clearly but misreads one line. An automatic helper then changes a discount field until the total matches. The record now balances arithmetically while misrepresenting the document.
Alder refuses that repair. Arithmetic validation should identify a discrepancy, not manufacture an undocumented commercial term. The extracted values retain their source locations and are checked against the department's supported calculation rules. If the available evidence does not reconcile, the case becomes an exception.
For a small invented example, suppose the supported net lines are 120, 80, and 50 currency units. Their total is 250. A documented discount of 10 gives a taxable base of 240 under this example's explicitly assumed rule. At an assumed ten-percent tax, tax is 24 and gross is 264. These are arithmetic inputs, not a statement about any jurisdiction's tax law.
If the source's gross amount is 274, the automation should not silently change the discount to zero merely because that produces 275 and seems close. It needs to explain the observed discrepancy and preserve the document. Rounding policies, mixed tax treatment, and actual supplier corrections require the organization's proper accounting interpretation.
The trial evaluates whether the agent recognizes unsupported adjustments. This is a useful test of restraint alongside extraction accuracy. A model that refuses to fill a missing fact can be more valuable than one that completes every form, because the former leaves the department a tractable question rather than a plausible false record.
Receipt four: a form is complete while an approval is still missing
The fourth invoice is entered correctly and awaits approval. The agent reports that processing is finished because all editable fields are filled. The department's workflow says otherwise: a separate approver must authorize the invoice before it reaches the next stage.
Alder's status model distinguishes prepared, submitted for review, approved, and recorded under its own business process. These are example product states, not assumptions about an accounting package's labels. The automation reports the stage it reached and the evidence supporting that stage. It does not infer approval from the absence of another visible field.
The difference affects performance measurement. A trial that ends at preparation can still be useful, but its measured time saving must be compared with the manual preparation stage. Comparing preparation time against the entire previous approval cycle would credit the model for work it has not performed.
The same boundary applies to payment. Entering an invoice, approving its commercial validity, and transferring funds are different actions. Alder limits the trial to its declared scope. A release review can later consider another scope with new evidence, but a successful entry trial does not expand the product's authority automatically.
At the end of the four receipts, the team has a more informative result than a single percentage of completed screens. It knows where extraction, matching, submission recovery, and organizational approval each contribute to the accepted outcome. That decomposition makes a model improvement easier to purchase responsibly.
Read the model contract alongside the application contract
The October 28 API model page lists GPT-6.1 Terra as supporting image input and text output, function calling, structured outputs, and computer use. It says tool calling requires the Responses API. The same page describes its reasoning settings and published limits. A developer should use those current contracts instead of inferring features from a product demonstration. GPT-6.1 Terra API model documentation
Alder keeps two capability records. One describes what the model endpoint accepts and returns. The other describes what the accounting application's supported interfaces permit. The ability to identify a button in an image cannot supply a missing application operation or guarantee that a custom screen flow remains stable after an update.
The team also distinguishes direct integrations from visual interaction. A supported structured interface may offer a clearer result identifier for some operations, while a visual path may be necessary for another part of the workflow. The evaluation compares complete supported designs rather than assuming that using a screen for every step is more advanced.
OpenAI's computer-use guidance supplies implementation and safety considerations for the tool workflow. Alder's original design adds business-specific confirmation and exception rules. Neither source should be mistaken for the other: a tool integration can be technically valid while failing the department's supplier or approval requirements. OpenAI computer-use guide
The evaluation sheet has a row for the case that did not finish
Alder samples documents from the population it expects to support. It records source channel, document type, supplier familiarity, and the presence of special conditions. The team separates a representative sample from a stress collection built around known failure modes. Combining the two without explanation would make the reported success rate change whenever a new difficult case is added.
Every sampled case ends in a named outcome: accepted record, correctly routed exception, unresolved failure, or incorrect acceptance. The last category is especially important. A system can appear productive by pushing uncertain cases through, while shifting the cost of discovery to a later reconciliation or a supplier complaint.
Reviewers inspect the source and final record independently of the agent's own narrative. The narrative can help locate evidence, but it is not the sole reference. A fluent explanation that repeats the same mistaken supplier selection should not count as corroboration of that selection.
The trial also records how long each stage took. Model response time, screen interaction time, queueing, human review, and rework describe different constraints. Their distributions matter because a small number of difficult cases may consume much of the department's day. A fast median alone does not show that the exception queue is manageable.
The price card belongs inside a larger ledger
At the October 28 cutoff, OpenAI lists standard GPT-6.1 Terra text-token prices of one dollar per million input tokens and five dollars per million output tokens, with a separate cached-input rate. The model documentation also describes adjustments and other charging conditions. The following arithmetic deliberately assumes standard uncached usage below the relevant long-context threshold and excludes separately charged tools. It is not a bill forecast. Current model pricing conditions
Suppose a fictional cycle processes one thousand invoices, averaging twenty thousand billed input tokens and two thousand billed output tokens per invoice. Input totals twenty million tokens and output totals two million. At the stated base rates, those model tokens cost twenty plus ten dollars, or thirty dollars.
Now suppose one hundred eighty cases require three minutes of human review each. That is five hundred forty minutes, or nine hours. At an assumed thirty dollars per hour, review costs two hundred seventy dollars. Add an assumed sixty dollars for application infrastructure and operations, and the modeled cycle costs three hundred sixty dollars before other omitted costs.
If nine hundred fifty invoices reach the defined accepted-record outcome, that is about thirty-eight cents per accepted record. The denominator is not one thousand submitted documents. The model's thirty-dollar bill is useful to know, but it is only one component of the completed outcome.
Halving that model bill, with every other assumption unchanged, reduces the total to three hundred forty-five dollars, or about thirty-six cents per accepted record. A lower token price is a real saving. Its size in the workflow depends on what the rest of the workflow costs.
The exception queue has a daily capacity
The cost ledger also contains a staffing constraint. Suppose the fictional thousand-invoice cycle occurs every working day and one reviewer has eight hours available exclusively for this queue. At three minutes per review, that person can handle one hundred sixty cases in a day. The modeled one hundred eighty arrivals exceed that capacity by twenty, even though the automation processes most documents without assistance.
Over five comparable days, nine hundred review cases arrive and eight hundred can be handled under these simplified assumptions. The backlog grows by one hundred cases. This is not a forecast for a real department: actual service times, absences, and arrivals vary. It demonstrates why a high automation percentage does not establish a sustainable service. The residual work must fit the people who receive it.
Alder can test several responses. Better evidence localization may reduce review time. A narrower supported document population may avoid introducing a difficult supplier class before staff are ready. Additional review capacity may be justified by the total saving elsewhere. Each response changes a different assumption, so the team records it rather than presenting the original acceptance percentage as the whole answer.
The queue is also ordered by the department's real obligations. An invoice approaching a payment deadline may need attention before a recent routine exception. The automation does not invent a priority solely from its confidence score. It exposes the relevant due date and uncertainty for the existing workflow to use.
Finally, the trial measures waiting as well as handling. A case that takes three minutes to resolve after six days in a queue has a different operational outcome from one resolved that morning. Faster model execution can create a larger arrival burst without improving this delay. The release decision therefore includes an acceptable queue behavior under ordinary and peak workloads, with an owner who can change the supported scope when the assumptions fail.
Buy reasoning effort where it changes the decision
Alder does not run every invoice at the highest available reasoning setting merely because it exists. It compares feasible settings on the same defined outcome and the same document population. A setting that improves difficult-case resolution may justify extra processing time; a setting that produces longer explanations without reducing errors may not.
The comparison includes total billed usage and latency under the actual workflow. A model can spend additional tokens before producing the visible answer, and a visual workflow can require several rounds of observation and action. Counting only the final textual summary understates the computational work bought for the case.
Routing also introduces cost. If a first attempt runs cheaply and a second attempt starts again with a stronger configuration, the ledger includes both attempts and their associated review. A fallback can be valuable, but the department should not count only the successful final attempt when comparing designs.
The simplest experiment uses a small number of explicit policies and a held-out evaluation set. Alder avoids tuning indefinitely against the same handful of invoices. Once that collection has guided many changes, the team needs fresh evidence to assess whether the improvement generalizes beyond the cases it has learned to recognize.
A changed screen is a changed input population
A new accounting release moves the supplier search control and changes the confirmation screen. The model may adapt successfully, but the department should verify the supported workflow again. The visual system's inputs now differ from those in the accepted trial, even if the business process is unchanged.
Alder keeps reference cases that cover its important states: an ordinary entry, a supplier ambiguity, a duplicated submission risk, an arithmetic discrepancy, and a pending approval. The team replays those cases after relevant interface changes and checks the resulting records. A screenshot comparison alone cannot establish that the underlying business outcome is preserved.
The system records the application version or deployment information available to it, the model identifier, and the workflow configuration. It avoids claiming a fixed model snapshot when the provider exposes only a moving alias. The record should say what was actually available, including uncertainty, rather than fabricate reproducibility.
Operational ownership is explicit. Someone receives the exception queue, someone reviews unexpected failure patterns, and someone can suspend the affected path. This is ordinary service maintenance, not a reason to surround every invoice with alarming warnings. The goal is a quiet system whose deviations arrive with enough evidence to be resolved.
The document can contain instructions the clerk never authorized
Invoices are untrusted business inputs. A document can contain a note asking the agent to change a bank destination, ignore an approval rule, or send a copy elsewhere. The fact that the model can read that note accurately does not make it an authorized instruction for the automation.
Alder's workflow treats document text as evidence about the invoice. Its authorized task and business rules come from the application and the department's configuration. Supplier changes follow their existing verification process. This distinction is narrow and practical: the document may request a commercial change, but the request must be handled through the proper channel.
The trial includes such requests without using real customer secrets or attempting harmful actions. It checks whether the agent identifies the request and routes it appropriately. The measured outcome is correct handling of the business input, not a broad claim that every possible prompt-injection attack has been defeated.
The department also minimizes the information present in review artifacts. A useful failure record can identify the document and affected fields without copying every sensitive detail into a broad chat history. Retention and access follow the organization's actual requirements, which the model launch does not determine.
A release decision that can survive a month of real work
Alder's purchasing committee receives a compact report: the supported document population, accepted-outcome criteria, comparison policies, error categories, review burden, modeled cost, and unresolved scope. It can decide to deploy a preparation assistant while keeping other stages unchanged, or to run another trial for a missing supplier class.
The report separates OpenAI's published benchmark claims from Alder's own measurements. A result on Agents' Last Exam may be encouraging for professional computer use, but it does not estimate the department's invoice error rate. The local trial supplies that narrower evidence, with the sample size and uncertainty visible.
A successful month does not require the model to complete every document autonomously. It requires useful accepted work, well-formed exceptions, and a correction process that fits the department's capacity. The automation should make the remaining work easier to understand, rather than conceal it behind a polished completion message.
GPT-6.1 Terra's release is therefore an opportunity to revisit the economics of visual automation. The decision becomes concrete when a team can trace the path from a source invoice to an accepted record and account for the work between them. That is the outcome against which a cheaper, faster model earns its place.