DEV Community: Duaer Team

Onboarding buddy program: what the buddy does, how much time it takes, and what they don't answer

Duaer Team — Mon, 12 Oct 2026 01:23:53 +0000

This article is AI-generated.

An onboarding buddy is the colleague a new starter can ask the small questions: where things are, how people actually do things here, who to talk to. When it works, new people settle faster and managers get fewer interruptions. When it doesn't, the buddy is either a name on a welcome email who never gets asked anything, or the person who ends up answering every question for three months.

This article covers how to set up a buddy program that holds up: what the role is, how much time to set aside, and a clear split between what the buddy answers and what should already be written down. It isn't about planning the first 30 days of training or about handling repeated questions in general. Examples are illustrative, with placeholder names.

Define the role in one paragraph

Write down what the buddy is for before you pick anyone. A version you can adapt:

The buddy helps the new starter find their way around in the first few weeks: introductions, everyday how-we-do-it questions, and pointing to the right document or person. The buddy is not the new starter's manager or trainer, and doesn't assess their work. (illustrative)

That last sentence matters. If the role isn't separated from training and management, the buddy ends up doing all three.

Choosing a buddy

Not the manager. New people ask different questions when the person can't judge them.
Been here long enough to know where things are, but close enough to the new starter's work to be useful.
Willing. Ask, don't assign. A reluctant buddy is worse than none.
Has the time. Agree it with their manager, so it isn't squeezed into lunch breaks.

Set the time explicitly

A buddy program fails quietly when nobody budgets the time. Agree on a rough shape up front, for example (illustrative):

Period	Buddy time
Week 1	A short check-in each day
Weeks 2–4	Two check-ins a week
Weeks 5–8	One check-in a week, then end

Put an end date on it. It gives both people permission to stop, and it's a natural point to ask what worked.

What the buddy answers, and what they don't

This split is the core of the program. Write it as a short table and give it to both people on day one.

Question type	Who answers	Example (illustrative)
Where is something / who do I ask	Buddy, then point to the document	"Where are the expense forms?"
How do people usually do this here	Buddy	"Do people book meeting rooms or just use them?"
Rules, policies, procedures	The written document; buddy shows where it is	"What's the approval step for purchases?"
How to do my actual job	Manager or trainer	"How do I prepare the weekly report?"
Anything about workload, priorities or personal matters	Manager

The buddy's most useful habit is "let me show you where that's written", not "here's the answer". Each time they point to a document, the new starter learns where to look next time. Each time they answer from memory, the knowledge stays in their head.

A buddy checklist

Give the buddy a one-page list (illustrative):

[ ] Day 1: introduce the new starter to the people they'll work with most
[ ] Day 1: show where the team's shared documents and procedures live
[ ] Week 1: lunch or coffee, no agenda
[ ] Week 2: ask what they've had trouble finding
[ ] Week 4: ask which questions they've asked more than once
[ ] End: pass the list of repeated questions to the manager

Turn repeated questions into documents

The last item on that checklist is where a buddy program pays off beyond one person. If a new starter asked the same thing twice, or the buddy answered it from memory, the answer probably isn't written down anywhere obvious. The manager decides whether to add it to the onboarding documents. The next new starter then finds it without asking.

Common pitfalls

Buddy becomes trainer. Keep the split table visible.
No end date. The relationship drifts and neither person knows if it's still on.
Buddy is the only source. If every answer comes from one person, nothing gets written down.
No feedback. Ask both people at the end what they'd change.

Wrap-up

A buddy program works when the role is narrow, the time is agreed, and the buddy points to documents rather than replacing them. Set those three things up and the program helps the next new starter too, not just this one.

How to track follow-up tasks so nothing quietly stalls

Duaer Team — Sun, 11 Oct 2026 01:18:31 +0000

Follow-up work is the stuff that happens after the "real" task: chasing a reply, checking that a fix actually shipped, confirming that a request someone promised to handle got handled. It's rarely hard. It just slips. One person in an automation forum listed the usual casualties: "a client wrote and nobody replied, a deal sat untouched for weeks, a payment was started and never finished."

None of those are failures of skill. They are failures of tracking. This article walks through a simple, tool-agnostic way to track follow-up tasks for yourself or a small team: what columns to keep, what each status means, how to run a weekly overdue review, and a formula you can drop into a spreadsheet to flag what's late. It isn't about meeting action items specifically; it covers any loose end that needs someone to come back to it.

Why follow-ups get lost

Follow-ups have three properties that make them easy to drop:

They're triggered by something else. You send an email and the follow-up is "check for a reply on Thursday". The original task feels finished, so the follow-up never gets written down.
They depend on other people. You can't complete them alone, so they sit in a vague "waiting" state with no date.
They're small. Nobody wants a project plan for "ping the supplier again", so they live in memory, chat history or a sticky note.

A tracker fixes all three if it does one thing well: every follow-up gets a line, an owner and a date the moment it's created.

Step 1: Pick one place

The specific tool matters much less than having exactly one. A spreadsheet, a task app, a plain text file—any of these works if it's the only place follow-ups live. The common failure is a split: some in email flags, some in a notebook, some in a chat "saved messages" list. Then the weekly review has to search four places and nobody does it.

If you're tracking for a team, use a shared spreadsheet or shared list everyone can see. Visibility is half the value: people follow up faster when the item has their name on it in public.

Step 2: Use a small set of columns

Here is a layout that works for most people. Keep it this small at first; add columns only when you notice you keep needing the information.

Column	What to write	Why it matters
ID	A short number (F-001, F-002…)	Lets you refer to an item in chat without retyping it
What	The follow-up as an action: "Get signed quote back from Supplier X"	A verb forces clarity about what "done" is
Owner	One name	Two owners means no owner
Waiting on	Who or what you're waiting for, if anyone	Separates "my move" from "their move"
Created	Date the item was added	Shows how long things really take
Next check	The date you'll look at it again	The single most important column
Status	One of the defined statuses below	Lets you filter
Done when	One sentence describing completion	Stops items closing too early
Notes	Latest update, with date	History without a separate log

Illustrative rows:

ID	What	Owner	Waiting on	Created	Next check	Status	Done when
F-014	Get signed quote back	Person A	Supplier X	2026-10-02	2026-10-08	Waiting	Signed PDF saved in contracts folder
F-015	Confirm login fix works for user	Person B	—	2026-10-09	2026-10-12	Open	User confirms they can log in
F-016	Reply to client question about invoice	Person A	—	2026-10-10	2026-10-20	Open	Reply sent and client acknowledged

Note the column called Next check rather than "Due". Many follow-ups don't have a real deadline, but every one of them needs a date when somebody looks again. If you leave this blank, the item is already lost.

Step 3: Define your statuses and stick to them

Statuses only help if everyone means the same thing. Four is usually enough:

Open — the owner needs to act next.
Waiting — someone else needs to act; the owner checks again on the next-check date.
Blocked — it can't move until something specific changes; the note says what.
Done — the "Done when" sentence is true. Not "mostly", not "I sent it".

Two rules make statuses trustworthy:

Every status change gets a dated note. "2026-10-08 chased by email, they said Friday" is enough.
Waiting always has a next-check date. "Waiting" without a date is how deals sit untouched for weeks.

Avoid adding statuses like "In progress" or "Almost done". They feel informative but don't tell anyone what to do next.

Step 4: Capture follow-ups at the moment they're created

The tracker is only as good as what goes into it. Build the habit of adding a line at the exact moment a follow-up is born:

You send an email that needs a reply → add a line with next check in two or three working days.
Someone promises to do something for you → add a line with them in "Waiting on".
You hand something to a colleague → add a line, owner is them, and tell them.
A ticket or request is "fixed" → add a line to confirm with the requester.

If adding a line takes more than thirty seconds, the tracker is too complicated. Trim columns until it doesn't.

Step 5: Flag overdue items automatically

A spreadsheet can do the nagging for you. Add a Flag column with a formula that looks at the status and the next-check date. Assuming Next check is in column F and Status in column G, put this in row 2 and fill down:

=IF(G2="Done","",IF(F2<TODAY(),"Overdue",IF(F2-TODAY()<=2,"Due soon","")))

What it does:

Done items show nothing.
If the next-check date has passed, it shows Overdue.
If it's within two days, it shows Due soon.
Otherwise it stays blank.

I tested the logic in LibreOffice Calc with a fixed reference date of 2026-10-11 in place of TODAY(): a Waiting item dated 2026-10-08 showed Overdue, an Open item dated 2026-10-12 showed Due soon, an Open item dated 2026-10-20 stayed blank, and a Done item dated 2026-10-01 stayed blank. Depending on your locale, LibreOffice may expect semicolons instead of commas between arguments.

Add conditional formatting so "Overdue" turns red and "Due soon" turns amber, then sort or filter by the Flag column. That view is your daily list.

Step 6: Run a weekly overdue review

Daily glances catch the urgent items. A weekly review keeps the tracker honest. Set a fixed fifteen-minute slot, same day each week, and go through it in this order:

Overdue first. For each one: act now, set a new next-check date with a note explaining why, or close it.
Waiting items. Has the other person gone quiet twice? Change the approach: call instead of emailing, or ask whoever can unblock it.
Blocked items. Is the blocker still real? If it's been blocked for more than two weeks, raise it with someone who can decide.
Items with no next-check date. There shouldn't be any. Add one.
Done items. Move them to a "Closed" sheet so the active list stays short. Don't delete them; the history is useful.

For a team, do this review together for the overdue items only, and keep it brisk. The goal is decisions, not status reports.

Step 7: Decide when to escalate

Some follow-ups will never close by politeness alone. A simple rule removes the awkwardness of deciding each time:

Second missed next-check on a Waiting item → change channel (phone, a direct message, or in person).
Third missed next-check → tell the person who asked for the work, or someone who can make the call.
Blocked for two weekly reviews → escalate with a one-line summary: what's needed, from whom, since when.

Write the rule at the top of the tracker so it's not personal when you apply it.

A checklist for a healthy tracker

[ ] Every item has exactly one owner.
[ ] Every non-Done item has a next-check date.
[ ] Every Waiting item says who it's waiting on.
[ ] Every item has a "Done when" sentence.
[ ] The Flag column shows no overdue items older than a week.
[ ] Done items have been moved out this week.

Common mistakes

Tracking tasks instead of follow-ups. The tracker becomes a full to-do list and the follow-ups drown. Fix: only add items that depend on coming back later or on someone else.
Shared ownership. "Person A / Person B" means each assumes the other did it. Fix: one name; mention the second person in Notes.
Closing on effort, not outcome. "Emailed them" isn't done. Fix: the "Done when" column.
Skipping the weekly review when busy. That's exactly when things slip. Fix: keep it to fifteen minutes and review overdue items only if time is short.
Endless date pushing. Moving next check forward without a note hides a stuck item. Fix: every date change needs a dated note, and the escalation rule applies after two misses.

Wrapping up

Tracking follow-up tasks comes down to a handful of habits: one place, one owner, a next-check date on everything, clear statuses, a formula that flags what's late, and a short weekly review. None of it needs a special tool. Start with the columns above, add your current loose ends today, and run your first review at the end of the week.

This article was drafted with AI assistance.

Meeting action items tracker: one table, one owner per row, overdue first next time

Duaer Team — Sat, 10 Oct 2026 23:35:19 +0000

This article is AI-generated.

Meeting notes often end with a few lines like "maintenance to look at it", "follow up with the carrier", "someone to update the checklist". A week later nobody can say which of those happened. The notes weren't wrong. They just didn't say who, by when, or what finished looks like.

This article gives you a tracker layout to replace the to-do section of your meeting notes: the columns, a worked before and after, and how to open the next meeting by walking through overdue items first. How to nudge and escalate between meetings, and how to track personal tasks outside of meetings, are separate topics. Names and items below are illustrative.

The columns

Column	What goes in it	What not to write
A ID	A running number that is never reused, e.g. WH-118
B Raised	Which meeting it came from
C Action	One action, starting with a verb	"Packaging issue"
D Owner	One person's name	"Procurement", "Person A and Person B"
E Due date	A real date	"ASAP", "next week"
F Done when	The visible result that closes it	"follow up", "look into"
G Status	Open, In progress, Blocked, Done
H Last update	Date of the latest note
I Notes	One line: what's blocking it, or the new date
J Days overdue	Formula
K Sort order	Formula

One owner per row. Two names means each person assumes the other is doing it. If several people are involved, name one owner and list the others as "with" in the notes.

"Done when" is the column people skip. "Follow up with the customer" can stay open for a month. "Send the complaint analysis to Person A" is either sent or it isn't.

Two formulas

Days overdue, J2:

=IF(OR(G2="Done",E2=""),"",IF(E2<TODAY(),TODAY()-E2,""))

Sort order, K2, so overdue rows float to the top and rows with no due date don't hide at the bottom:

=IF(G2="Done",4,IF(E2="",1,IF(E2<TODAY(),2,3)))

1 is "missing a due date", 2 is "overdue", 3 is "on time", 4 is "done". Sort the sheet by column K, then by due date. Rows with no owner or no due date are the ones to fix before you even look at overdue items, because they will never become overdue on their own.

With illustrative data, assuming today is 2026-10-09:

ID	Raised	Owner	Due	Status	Days overdue	Order
WH-101	2026-09-25	Person A	2026-10-02	Open	7	2
WH-102	2026-09-25	Person B	2026-10-16	In progress		3
WH-103	2026-09-25	Person C	2026-10-05	Done		4
WH-110	2026-10-02	Person B	2026-10-07	Blocked	2	2
WH-111	2026-10-02	Person D	(blank)	Open		1

(illustrative data; formulas tested on this sheet in LibreOffice; the syntax is the same in Excel, but I haven't run each one in Excel itself)

WH-111 sorts above the overdue rows on purpose: until it has a due date, it can't be tracked at all.

Before and after

Before (illustrative), from a weekly warehouse meeting:

Action items: Dock door 4 keeps jamming, maintenance to look at it. Late carrier pickups again this week, follow up. Returns checklist is out of date, someone to update. Label printer on packing line 2, ASAP. Person A and Person B to sort out the cycle count backlog.

After (illustrative):

ID	Action	Owner	Due	Done when
WH-118	Book a repair for dock door 4	Person C	2026-10-12	Repair date confirmed in the maintenance log
WH-119	Send the carrier a list of this week's late pickups	Person A	2026-10-10	List sent, reply requested by 2026-10-14
WH-120	Update the returns checklist to the current process	Person D	2026-10-16	New version saved in "warehouse/checklists", old one moved to "retired"
WH-121	Get the packing line 2 label printer fixed or swapped	Person B	2026-10-10	Line 2 printing labels again
WH-122	Clear the cycle count backlog for aisles 1–6	Person A (with: Person B)	2026-10-20	Counts entered for aisles 1–6

(illustrative)

Every "before" line was a real concern. What was missing: "maintenance" and "someone" aren't people, "ASAP" isn't a date, "follow up" has no end, and two names on one line meant nobody owned it. The "after" version fixes those four things and nothing else.

Anything with no action and no owner, such as "everyone please keep aisles clear", stays in the notes as a reminder and stays out of the tracker.

How to run the tracker at the next meeting

Before the meeting, the person who writes the minutes sorts the tracker by column K and filters out Done.
Open the meeting with the tracker, in this order: rows with no owner or no due date, then overdue, then due before the next meeting.
Overdue rows get a new date in the notes, not in the due date column. Keep the original due date so the days-overdue column stays honest.
A row is only Done when its "done when" is met. "Mostly done" stays In progress with a note.
New actions from this meeting get added before you leave the room, or within the same day. A tracker updated three days later has already lost the details.

Keep this part short. If reviewing the tracker takes the whole meeting, the tracker has too many open rows, which is itself useful information.

A few rules that keep it usable

One tracker for the meeting series, not a fresh list inside each set of minutes. Minutes link to the tracker by ID: "see WH-120".
IDs never get reused. When an action is split, the original stays and the new part gets a new ID.
Blocked needs a name. A Blocked row should say in the notes who it's waiting on, otherwise it sits there indefinitely.
File name and location, not "see attachment". If an action produces a document, the notes say where it is, for example warehouse/checklists/returns-checklist_v4 (illustrative).

How to combine multiple Excel files with different columns into one fixed report, and check the totals

Duaer Team — Thu, 08 Oct 2026 01:16:56 +0000

If you work in operations, admin, a PMO or a budget office, you probably know the routine: every month or quarter, several projects, departments or regions each send you their own file or sheet, and you roll them up into one report with a fixed layout that goes to leadership or finance.

Disclosure: I'm on the Duaer team, and this article was drafted with AI help.

The merge itself is rarely the hard part. The hard parts are that no two sheets look alike, and that once the report is done, nobody can quite explain why the total is the number it is. This article walks through a method you can reuse every period: a column mapping table, a fixed set of cleaning rules, an exceptions table that separates "included after a fix" from "excluded", a reconciliation page that ties every number back to its source, and an acceptance checklist you can copy.

The images below come from an illustrative demo workbook we built: four regional source sheets, a merged detail sheet, an exceptions sheet, a summary report and a checks page. Every number in it is randomly generated, and row 1 of every sheet says so. None of it comes from a real business or a real transaction.

Why "everyone fills in their own sheet" goes wrong

When the sheets come from different people, a predictable set of problems shows up period after period:

Different column names and order. One region calls it "Order ID", another "Order #", a third "Order No". Dates are in column A in one sheet and column B in the next.
Mixed date formats. One sheet has real dates. Another has text such as 2026/7/3. A third has text such as 3 Jul 2026.
Amounts stored as text with commas. The cell shows 4,420.00, but it is a string. SUM quietly skips it, the total comes out low, and nothing warns you.
Subtotal rows mixed into the data. Someone adds a "month total" row at the end of each month. Treat it as an order and that month is counted twice.
Blank rows and exact duplicates. Left over from copy and paste.
One order ID on two rows with different quantities. The dangerous one, because there is no way to tell from the sheet which row is right.

None of these is hard to fix once. The problem is fixing them every period, slightly differently each time. The goal is to turn each fix into a written rule, keep the rules in the workbook, and leave a trail anyone can follow.

Before you start

Pin down the report layout. The best spec is last period's report, the one that was accepted. Which columns, which breakdown (for example month by region), where the totals sit. Once the layout is fixed, each period only the data changes.
Keep an untouched copy of every source sheet. Never clean in place. Every check later on goes back to the original, and an edited original cannot be reconciled.
Count the raw data rows per sheet. Everything below the header, including blank and subtotal rows. That count is where your reconciliation starts.
Decide what you don't want anyone deciding for you. If an order appears twice with different quantities, do you want the person doing the merge to pick one, or to list both for you to confirm? I'd strongly suggest the second.

Step 1: Build a column mapping table

The mapping table answers one question: for every column in every source sheet, which unified field does it feed, and what was done to it? It is the instruction sheet for the job. Next period you follow it again; if someone else takes over, they follow it too.

Here is the mapping sheet from the illustrative demo:

A header you can copy (illustrative values, swap in your own column names):

Unified field	Sheet A column	Sheet B column	Sheet C column	Handling
Order ID	Order ID	Order #	Order No	Kept as is; used for duplicate checks
Date	Date	Date (text, 2026/7/3)	Order time (text, 3 Jul 2026)	Converted to real dates, shown as YYYY-MM-DD
Region	(none)	(none)	(none)	Filled in from the sheet name
Amount	Amount	Amount (text with commas)	Deal amount	Commas removed, converted to numbers; blanks go to Exceptions
(not used)			Notes	Not in the report; kept in the source

Three rules for a good mapping table:

Every column of every sheet appears. Columns you don't need are listed as "not used", so the next person knows they were dropped on purpose.
The Handling column states a rule, not an outcome. "Commas removed, converted to numbers" works next period too. "Fixed" doesn't.
Fields the report needs but the sources lack say where they come from. Region from the sheet name, month from the date.

Step 2: Clean by category, with a fixed rule for each

With columns aligned, work through the problem types in this order. For each one, decide what happens to the row and where the evidence goes.

Text amounts. Strip the thousands separators and convert. A helper column in Excel or Sheets does it:

=VALUE(SUBSTITUTE(E3,",",""))

Mixed dates. Normalise text into something unambiguous before converting. DATEVALUE on a string like 3 Jul 2026 depends on your locale settings and failed in one of our test environments, so for that pattern a lookup on the month abbreviation is safer:

=DATE(VALUE(RIGHT(B3,4)),
      MATCH(MID(B3,FIND(" ",B3)+1,3),{"Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"},0),
      VALUE(LEFT(B3,FIND(" ",B3)-1)))

For 2026/7/3, =DATEVALUE(SUBSTITUTE(B3,"/","-")) worked in our tests. Whatever you use, spot-check a few rows afterwards and confirm every date falls inside the reporting period.

Subtotal rows. They are not orders, so they stay out of the detail. Don't just throw them away, though. A subtotal is a number the sheet owner calculated themselves, which is exactly what you want to reconcile against later. Log each one in the exceptions table as "excluded, used as a cross-check".

Blank rows. Excluded, but logged with sheet and row number, so the gap between raw rows and merged rows can be explained line by line.

Exact duplicates. Only treat a row as a duplicate when the order ID and every other column match. Keep the first occurrence and log the rest. Building a key from the whole row is more reliable than checking the order ID alone:

=COUNTIF(K3:K2000,K3)

Here column K joins order ID, date, product, quantity and amount with a | separator; anything above 1 is a duplicate.

Same order ID, different quantity. Do not guess. "Keep the larger one" or "keep the later one" sounds reasonable, but either way you have made a business decision for someone else. Exclude both rows, list them as waiting for the owner's call, and add the confirmed row back once you hear.

Blank amounts. Two cases. If quantity and unit price are both present, you can fill in quantity × unit price and include the row, but it must be listed in the exceptions table so everyone knows the number was calculated. If quantity is missing too, leave it out and wait; don't estimate.

Step 3: An exceptions table that separates "included after fix" from "excluded"

Every row that was skipped, recalculated or put on hold goes into one exceptions table. This is the one from the illustrative demo:

Header to copy:

Source sheet	Source row	Order ID	Issue	Handling	Included	Amount involved

The "Included" column takes only Yes or No:

Yes means the row was corrected and is in the merged detail. The exceptions table is simply telling you it was touched.
No means the row is not in the merged result at all: blanks, subtotals, duplicates, and anything waiting for confirmation.

In this illustrative demo file, the four source sheets hold 6,324 raw data rows in total and the merged detail holds 6,303. The exceptions table has 25 rows: 21 excluded and 4 included after the amount was recalculated as quantity × unit price. The 21 excluded rows are 8 exact duplicates, 3 blank rows, 3 monthly subtotal rows, 3 rows with neither amount nor quantity, and 4 rows belonging to two order IDs that each appear twice with different quantities. Those four are all left out until the owner confirms. 6,303 plus 21 is 6,324, so every raw row is accounted for.

Step 4: A reconciliation page that explains the total

This is the page worth the most effort. It doesn't ask whether the report looks right; it asks whether a handful of equations hold. The checks page from the illustrative demo:

Three groups of checks cover most of the risk.

Per sheet, rows and amounts. One line per source sheet: raw data rows, merged rows, excluded rows from the exceptions table. Then the source amount calculated under the same rules, and the merged amount.

=IF(B3=C3+D3,"Match","Mismatch")
=IF(ROUND(F3-G3,2)=0,"Match","Mismatch")

"Calculated under the same rules" is doing real work there. Text amounts are summed after stripping commas. A sheet with subtotal rows is summed without them. A sheet with recalculated amounts adds those back. A sheet with excluded duplicates subtracts them. If the check uses different rules from the cleaning, it proves nothing.

Existing subtotals against merged totals. If a source sheet came with its own monthly subtotals, compare each one with the merged total for the same region and month. When the owner's own arithmetic agrees with your merge, you know no rows went missing or got doubled in between.

Report total against merged detail total. Build the summary report entirely from formulas that point at the merged detail (SUMIFS by month and region, for example), so the two totals should be equal by construction. When they aren't, it is usually a month or region label written slightly differently and silently left out.

In the illustrative demo, that adds up to 12 checks: 4 row checks, 4 amount checks, 3 monthly subtotal checks for the North sheet and 1 grand-total check. All 12 show "Match".

Acceptance checklist (answer yes or no to each)

[ ] The column mapping covers every column of every source sheet; unused columns are marked "not used"
[ ] The report's columns, breakdown and total positions match the agreed fixed layout
[ ] Every date in the merged detail is a real date and falls inside the period
[ ] Every amount, quantity and unit price in the merged detail is a number, not text
[ ] Every merged row carries its source sheet and source row, and a few picked at random trace back correctly
[ ] Per sheet: raw data rows = merged rows + excluded rows in the exceptions table
[ ] Per sheet: source amount under the cleaning rules = merged amount
[ ] Each existing subtotal in a source sheet (if any) = the matching merged total
[ ] Report grand total = merged detail amount total
[ ] Every exceptions row states the issue, the handling and Yes/No for included
[ ] Every recalculated row is listed in the exceptions table with how it was calculated
[ ] Rows sharing an order ID with different content were not resolved by guessing and are listed for the owner

Hand the report over only when every line is yes.

Common pitfalls

Text amounts skipped without warning. SUM ignores text and doesn't complain. Add "every amount is a number" to the checklist, and calculate the per-sheet source amount from comma-stripped values.

Subtotal rows counted as orders. They look like data rows with a blank order ID. Pull them out before merging, log them as exceptions, and add "existing subtotal = merged total" to the checklist.

Deduplicating on order ID alone. A repeated ID can be a pasted copy or two genuinely different records. Remove only exact duplicates automatically; list the rest.

Dates landing in the wrong month. Day and month get swapped, and 3 July becomes 7 March. Check that every date is inside the period, and compare row counts per month with last period.

Hand-typed numbers in the report. Typed in under deadline pressure, they break the moment next period's data arrives. Keep every report cell a formula, and say so in the checklist.

Logging what was dropped but not what was recalculated. Recalculated rows feel finished because they're in the result. Log both kinds, with the Included column filled in every time.

Handing it off

If you pass this job to a colleague or to an AI, give them three things up front: the original source sheets, last period's accepted report, and your preference for rows that need confirmation. Ask for the mapping table, the exceptions table and the reconciliation page back, then go down the checklist.