Transcript processing read twice, proven against the grade key, and posted the same day
Every course line read twice, reconciled to the grade key, and posted the same day.
See one case, screen by screen ↓Transcript Processing Automation reads every transcript twice: two reader agents on different models read the same page independently, without seeing each other's answer, and a checker agent resolves a disagreement only when the grade key, the school's grading scale or the totals printed on the page prove one reading. A scale agent recomputes the GPA and compares it with the one printed on the transcript, and records staff work only the rows the agents could not settle — about one line in two hundred.
AI in education: a buyer's guide to agentic AI for colleges, universities and school districts →
Updated
Transcript processing is the work of turning a scanned, mailed or electronic transcript into courses, grades, credits and GPA on the student record — thirty-one course lines, five different ways of writing a grade, a weighting scale that belongs to one high school and nobody else, and a cumulative GPA printed in a corner that may or may not agree with the lines above it. Today a records specialist keys all of it by hand, and a second specialist re-keys a sample to check the work.
A single reading has nothing to check it against: nobody catches a misread grade until a student disputes it or a degree audit comes out wrong years later. The grade key that explains a school's scale is usually on the back page, in six-point type, and the printed GPA — the one cross-check that exists on the document — is rarely recomputed by hand. Peak is not a slope but a wall: thousands of final transcripts land in June and July against a records office sized for the rest of the year, and correcting a record already posted touches the student information system, the degree audit and sometimes financial aid eligibility.
Estimated split of a typical transcript's minutes, by hand and with the agents. The published range for manual review is 20–60 minutes per transcript (Hyland, Aug 2026; degreesight.com); the after column totals the live solution's 9-minute median — our arithmetic, kept modest.
Two reader agents read every transcript independently, a checker reconciles them against the grade key, and a records specialist posts.
Elena Marchetti, applicant HSU-A-2026-184402, sends her final transcript from Brenmoor High School into Halden State University's Admissions Operations & Records. Here is what happens next, screen by screen, in the working solution.
Elena's final transcript arrives over the e-transcript network: two pages, a weighted 5.0 scale, 31 course lines, a grade key on page 2, and a cumulative weighted GPA of 4.12 and unweighted 3.71 printed on page 1. The intake agent matches it to her application, marks it final, and supersedes the mid-year report received February 12.
"2 rows need you" — the agreement strip above the grid.
Reader A and Reader B read all 31 lines independently, on different model families, and agree on 29. On row 19, Honors Chemistry, Reader A reads the grade as B+ with confidence 0.96; Reader B reads 8+ with confidence 0.41, because a toner smudge cuts through the character. On row 14, Spanish III, the readers disagree on whether the printed term SP 24 means Spring or Summer 2024.
The grade key on page 2 reads "B+ = 3.3 · Honors +0.5 · AP +1.0" — "8" is not a grade on this key. With B+ the 31 lines add to 103.00 weighted quality points over 25.00 credits, which prints as the 4.12 on page 1; with B they add to 102.70, which prints as 4.11. Only B+ makes both printed GPAs add up, so the checker proposes B+ and shows the arithmetic.
No total printed on the transcript depends on the term, so the checker cannot settle row 14 arithmetically. It offers no proposal, explains why, and gives the row to a records specialist with both readings and the page region each came from.
Anika approves row 19 with reason code R-02, "Grade key proves the reading", and sets row 14 to Spring 2024 with R-05, reading the term from the school calendar printed on page 1. Every row now carries two green dots, and the recomputed unweighted GPA of 3.71 and weighted 4.12 match what is printed on the transcript.
Anika approves the transcript for posting. The posting agent writes all 31 course lines and the three GPAs to the student information system and the admissions CRM, and records receipt SIS-POST-2026-07-07-00418 — twelve minutes from arrival to posted.
The posting agent never writes before a records specialist approves.
On Elena's peak July day the office read 1,284 transcripts and 23,906 course lines. The two readers agreed on 97.4% of them; of the 622 rows that disagreed, the checker proved 503 from the grade key or the printed totals, leaving 119 rows — one line in two hundred — for a records specialist, with a median of 9 minutes from arrival to posted.
233 rows from 19 transcripts the two readers agreed on are drawn at random and given to Marcus, who did not decide any of them himself. This month 4,180 rows have been sampled this way, with 3 corrected and 99.93% confirmed against a person — the agreement rate measured every day, not claimed once.
"Today's sample belongs to Marcus Ihejirika and contains none of the rows he decided himself."
The same transcript, seen by the four people who carry it — what their day looked like, and what it looks like now.
Two reader agents read every transcript independently, a checker reconciles them against the grade key, and a records specialist posts.
Picks transcripts up from the e-transcript network, the application portal, scanned mail and the transcripts mailbox; splits multi-page files; matches each to an applicant; marks it final, mid-year or in-progress; fingerprints the file.
Reads every course line — course, term, grade, credits, weighting — plus the totals, the GPA block and the grade key, citing the page and region of every value.
Reads the same transcript independently, on a different model family from Reader A, so agreement between the two is genuine evidence.
Compares the two readings row by row, and resolves a disagreement only when the grade key, the school's grading scale or a total printed on the page makes one reading arithmetically necessary, showing that arithmetic.
Converts weighted, 100-point, letter and pass/fail scales to the university's recalculated GPA; recomputes cumulative weighted and unweighted GPA and compares both with the GPA printed on the transcript; counts rigor.
Finds earlier transcripts from the same school for the same applicant and drafts the line-by-line comparison of what changes if the later one supersedes.
After a records specialist approves, writes the course lines, the GPAs and the rigor count to the student information system and the admissions CRM, and records the receipt.
Decides every row the agents could not settle, and signs every posting. The agents propose; a named person decides.
13 screens from the working solution, on its sample data. Pick one to see it large.
The rules every transcript is checked against are settings, versioned and on the audit trail.
| Setting | Default | Choose from |
|---|---|---|
| Rows that must reach a person | Any row two readers read differently that the checker cannot prove | Set by the director of admissions operations, with the associate registrar's signature |
| Reader B model | A different model family from Reader A | Set by the administrator, with the associate registrar's signature |
| Printed-vs-recomputed GPA tolerance | 0.00 — any difference blocks posting | Set by the associate registrar |
| Daily sample rate | 1 in 100 agreed rows, assigned to a specialist who did not decide them | Set by the director of admissions operations |
| Queues and SLAs | Final high school transcripts 1 business day · college transcripts 2 · mid-year reports 3 | Escalate at 80% of the clock |
| Confidence floor per reader | 0.55 — below it the reader records "unreadable" rather than a guess | Set by the administrator |
| Retention | Applicant transcripts 3 years if never enrolled; posted transcripts on the university records schedule | Set by the administrator, with the associate registrar's signature |
| Redaction on export | Government identifier block and date of birth masked in every export | Set by the administrator |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
"target" = design goal, measured in the live solution · "demo" = seen in the working solution, on its sample data · "typical" = published figures (Hyland, Intelligent Transcripts, Aug 2026 — more than 20 minutes per document; degreesight.com on 20–60 minute manual review; Common App 2025-26 volume) · "estimated" = our arithmetic, kept modest. Halden State University, Brenmoor High School and the people named on this page are fictional — characters and sample data in the working solution.
Transcript Processing Automation reads every transcript twice: two reader agents on different models read the same page independently, without seeing each other's answer, and a checker agent resolves a disagreement only when the grade key, the school's grading scale or the totals printed on the page prove one reading. A scale agent recomputes the GPA and compares it with the one printed on the transcript, and records staff work only the rows the agents could not settle — about one line in two hundred.
Keying a transcript by hand typically runs 20 to 60 minutes, and Hyland reports more than 20 minutes per document industry-wide. With two agents reading independently and a checker proving what it can, the median from a transcript arriving to its rows posted is a design target of 9 minutes, measured in the live solution.
A grade key is the table, usually on the back page of a transcript, that explains what a school's letters or numbers mean — for example B+ = 3.3, with Honors adding 0.5 and AP adding 1.0. Grading scales are local: the same letter can carry a different number of quality points at another school. The scale agent cites the grade key's version on every converted grade, and never edits the table itself.
Grading scales are not standard — weighted, 100-point, letter and pass/fail scales all exist, and honors or AP weighting differs by school — so the GPA printed on a transcript is not comparable across schools. The scale agent recomputes a weighted, unweighted and institution-specific GPA from the lines it read and compares both recomputed totals with the GPA printed on the page as a check on the reading itself.
No. The agents read, compare and recompute; they never post a course line to the student information system before a records specialist approves it, never edit a grading-scale table, and never supersede a posted record. A disagreement the checker cannot prove always goes to a person with both readings and the page region each came from.
Yes. A records specialist decides every row the agents could not settle and approves every posting by name; a second specialist re-checks a random daily sample of the rows the agents agreed on; and the associate registrar signs any change to a record already posted and every change to a grading-scale table.
Yes. Which rows must reach a person, the Reader B model, the printed-vs-recomputed GPA tolerance, the daily sample rate, queues and SLAs, each reader's confidence floor, and retention and redaction on export are all settings, versioned and on the audit trail.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your grading-scale tables, grade keys and a sample of past transcripts — and it goes live once every quality gate has passed. We will walk you through it on your own transcripts first.
The reader scores first; the agent's score opens beside it, cited to the page.
1-min demoTransfer Credit EvaluationCredit decided in a day, not a week, with every outcome threaded to the syllabus.
1-min demoCredit for Prior Learning EvaluationCredit earned before day one, with every credit tied to the evidence it rests on.
1-min demoWe'll run Transcript Processing Automation on a sample of your own past transcripts.