You receive about a hundred daily CSV files of sales transactions and have to turn them into one revenue journal entry. Doing that by hand is not realistic, so you direct an AI to write the code that reads the files, screens them for odd records, and builds the entry in a set format. The AI itself is not deterministic, but the code it writes is, so re-running that code reproduces the same journal entry every time.
Accounting is full of high-discipline tasks that have to produce the same output every time. Closing revenue is one of them. In this lab you are handed a folder of daily point-of-sale files, one file per day, and asked to produce a single revenue journal entry for the period. The files stack together into a population of a few thousand transactions, which is more than you want to add up by hand and exactly the kind of repetitive, rule-bound work that automation is for.
Start by assuming the files are correct and complete. Nothing gets filtered out of the journal entry, because the entry is meant to reflect every sale that was rung. Your job is to read all of the files, total them the way a revenue entry totals them, and produce the entry in the format we give you.
The data also carries some odd records, the way real exported data does: a few extreme amounts, a few negatives, some zero prices, a couple of duplicated ids, and some bad dates. Here is the part that trips people up. You still include those odd rows in the journal entry, because the entry is auto-created from every transaction and you are treating the source as correct. You screen for them anyway and write them to a second file, so a reviewer can find them later if the entry has to be backed out and rebooked. The odd rows are flagged, not removed.
This is a vibe-code lab. You do not write the parsing and totaling code from scratch, and you do not get a worked solution. Instead you direct an AI to write the code that reads the folder, screens for odd records, and aggregates the transactions into the journal entry in the format we hand you. You describe what you want, the AI drafts the code, and you review it, run it, and correct it until the output is right.
The reason this counts as reliable automation is worth being precise about. A large language model is not deterministic. Ask it the same question twice and you can get two different answers, so you would not want the model itself deciding your revenue number on each run. The code it writes, though, is ordinary Python, and ordinary code is deterministic: given the same files it produces the same journal entry every single time. So you use the non-deterministic model once to author a deterministic program, then you lean on the program from then on. That split, a model that writes the automation and code that runs it, is the whole point of the lab and the thing the homework asks you to explain.
You are building a revenue journal entry. The cash collected on a sale is the sale amount plus sales tax, and the entry splits that gross figure into net revenue and the tax you owe the state. With a fixed 7.25 percent sales tax, the three lines are:
| Account | Debit | Credit |
|---|---|---|
| Cash | total amount + total tax | |
| Sales Revenue | total amount | |
| Sales Tax Payable | total tax |
The debit equals the sum of the two credits, so the entry balances, or foots. The tax column in the data is already computed as round(amount * 0.0725, 2) per row, so you total the amount and tax columns directly rather than recomputing the rate. Sales Tax Payable is the sum of that per-row tax column, not the period total times 7.25 percent. Because each row is rounded to the cent first, the two can differ by a penny, so sum the column. Match the columns in the template exactly: account, debit, credit.
This is where the statistical work from across the term comes back. You have looked at percentiles, spread, and outliers all semester, and this is a concrete place to use them. There is no single right method here, and you do not have to catch a fixed list. Pick a defensible approach, apply it, and write a short note in the notebook on what you did and why.
A few methods that each surface a reasonable set:
amount < 0 or unit_price == 0 flags those directly.transaction_id is normally unique, so an id that appears on more than one row is worth flagging.You can combine methods, and reasonable people will flag slightly different sets. What matters is that your flags are defensible, each flagged row carries a plain-language reason, and your note explains the method. Remember the two rules: the odd rows stay in the journal entry totals, and they also go into the flagged file.
Everything you need is linked below. The transactions ship as a single transactions.zip that your code downloads and unzips, which is part of the exercise: there is no one combined file, so you read the folder and stack the daily files together. Read the data dictionary first; it names every column and tells you which records are odd on purpose.
transactions/ folder. This is the raw URL your notebook fetches.journal_entry.csv must match (account, debit, credit).flagged_transactions.csv (transaction_id, date, amount, reason, method), with two example rows..ipynb) is the deliverable; Excel here is only a way to check it. Power Query is a good way to do that: download transactions.zip, unzip it, and load the whole transactions/ folder (Data → Get Data → From Folder), then total the amount and tax columns and confirm the totals and row counts match what your notebook produced. You can also check your numbers and counts against the Transaction review page, for example total revenue and the rows per file, to confirm every file loaded.glob to list the files that match transactions/txn_*.csv, then pandas.concat to stack them into one DataFrame. The starter notebook already does this in its first cells, so you can focus on the totaling and the screening. If you get stuck on the folder read, ask the tutor to walk you through it.build_journal_entry(df) and build_flagged(df), that each return a DataFrame you then write to CSV. Defining each output once, in one place, keeps the logic together and means you can re-run it and get the same result rather than tracking down ad hoc code spread across cells. It also makes the two rules easy to keep straight, since the journal-entry function totals every row while the flagged function only copies the odd ones out.The chat in the corner should appear on its own. If it does not, copy the prompt below into ChatGPT, Claude, or Gemini in another tab, add your own plan and your specific question, and it will coach you the same way.
You are a coding coach for an accounting analytics lab. I am directing you to help me VIBE-CODE an automation in Python (pandas), in Google Colab. The task: read about a hundred daily transaction CSVs (glob + pandas.concat), build one REVENUE journal entry, and write a second file of odd records for review. The revenue journal entry has three lines and must balance: Dr Cash = total amount + total tax Cr Sales Revenue = total amount Cr Sales Tax Payable= total tax Tax is already computed per row as round(amount * 0.0725, 2), so total the amount and tax columns directly. Output columns: account, debit, credit. Screening: flag odd records (extreme amounts via IQR/percentile/z-score, negative amounts, zero unit prices, duplicate transaction_id, unparseable or out-of-range dates). IMPORTANT: the odd rows STAY IN the journal entry totals; they are only copied out to flagged_transactions.csv (columns: transaction_id, date, amount, reason, method) so the entry could be backed out and rebooked later. Coach me and help me debug. Do NOT write the whole finished journal-entry program for me and do NOT give me a final revenue total. Push me to try first. Here is my plan and my question:
Before you hand anything in, check that your automation actually read everything and totaled it correctly. Reading a folder is a common place for files to go quietly missing, a path that does not match the glob, a file that fails to parse, a stray copy that gets counted twice, and the totals can still look reasonable even when a whole day is dropped. A completeness check is exactly what catches that, which is why it is a step and not an afterthought.
A few ways to check, and any one of them is enough:
txn_*.csv files, total them in a quick cell, and confirm those rows show up in your stacked DataFrame with the same amounts.Whichever you use, write down what you checked and what it told you. That short note is one of the things you hand in.
Four things, all to the Lab 10 assignment in the Week 10 module.
.ipynb). The Colab notebook that reads the transaction files, screens for odd records, and builds the journal entry. Keep your short note on the outlier method you chose inside the notebook, next to the code that flags the rows. Run every cell top to bottom before you download so the outputs are saved, then use File → Download → Download .ipynb.
journal_entry.csv). Your revenue journal entry in the template format (account, debit, credit), the three lines that foot. The totals include every transaction, odd rows and all, because the entry is auto-created from the full population.
flagged_transactions.csv). The odd records you screened out for review, in the template format (transaction_id, date, amount, reason, method). These rows are flagged, not removed. They are still in the journal entry above; the flagged file just gives a reviewer a way to find them if the entry ever has to be backed out and rebooked.
journal_entry.csv follows je_template.csv and your flagged_transactions.csv follows flagged_transactions_template.csv. Matching the columns is what makes the automation checkable.The transactions are synthetic teaching data built for ACCTG 5150. No real customer or company data is used.